Funktioniert mit meinen beiden HQ Dateien!
Was nicht funktioniert ist das anschließende Verschieben der "Müll-Dateien" in ein anderes Verzeichnis -> es wird nur die OTRKEY-Datei verschoben, der Rest bleibt stehen
@gilbert:
Die avi-Datei wird also nach dem Schneiden nicht verschoben?
Ich habe es einmal in einer Ubuntu 20.04 VM getestet und dort funktioniert das Verschieben.
Starte otrv bitte im Terminal: otrverwaltung3p -d
Funktioniert das Verschieben mit dem Button "in den Müll verschieben"? Falls nein, was "sagt" das Terminal?
Prüfe bitte den Pfad "Müll für avis". Ist er gültig und schreibbar?
Hallo Leute.
Vielen Dank, es läuft.
Das Anpassen der Rechte hatte noch keine Änderung gebracht.
@loreotr:
Nach dem Einspielen der angepassten otrverwaltung3p lief die Anwendung sofort.
Gruß
Frank
Die Meldungen im Terminal sprengen den Rahmen hier auf diesem Board :confused:, ich hab sie daher in eine seperate File gespeichert
Command line
@gilbert:
Danke für das Log.
Nochmals gefragt:
Funktioniert das Verschieben einer Datei in den Müll mit dem Button "In den Müll verschieben"?
Falls nicht, öffnet sich ein Fenster mit einer Fehlermeldung?
Edit:
Ich sehe gerade, dass die Terminalausgabe unvollständig ist: Es wurde eine Datei geschnitten, aber die Zusammenfassung wurde nicht geöffnet (Du hast nicht den Button "Eine geschnittene Datei anzeigen" geklickt, sondern das Programm beendet).
Dadurch fehlt alles, was mit dem Verschieben der Dateien zu tun hat.
Edit: Neues Paket:
otr-verwaltung3p-dev-1.0.0b8-2.deb, das den Patch enthält.
werde ich nochmals testen!
Hier noch das Szenario auf ZorinOS (Ubunt18.04 Basis)
Code:sudo dpkg -i otr-verwaltung3p-dev-1.0.0b8-2.deb
[sudo] Passwort für gilbert:
(Lese Datenbank ... 411455 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von otr-verwaltung3p-dev-1.0.0b8-2.deb ...
Entpacken von otr-verwaltung3p-dev (1.0.0b8) über (1.0.0b8) ...
otr-verwaltung3p-dev (1.0.0b8) wird eingerichtet ...
File "<fstring>", line 1
(response = )
^
SyntaxError: invalid syntax
dpkg: Fehler beim Bearbeiten des Paketes otr-verwaltung3p-dev (--install):
Unterprozess installiertes otr-verwaltung3p-dev-Skript des Paketes post-installation gab den Fehler-Ausgangsstatus 1 zurück
Trigger für desktop-file-utils (0.23-1ubuntu3.18.04.2+zorin1) werden verarbeitet ...
Trigger für gnome-menus (3.13.3-11ubuntu1.1) werden verarbeitet ...
Trigger für mime-support (3.60ubuntu1) werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
otr-verwaltung3p-dev
so, das Verschieben in Müll und Archiv funktioniert bestens, war mein Fehler! Jedoch beim Umbennen, vorallem bei den Umlauten klappt es noch nicht so wie gewünscht (siehe Command Line 2) oder liegt es da wieder an einem Bedienungsfehler meiner seits :o
Ich weiß nicht genau was dies bedeuten soll, aber falls Du auf die Buttons Ersetzen: "Leerzeichen" "Umlaute" anspielst:Zitat:
(...)
Jedoch beim Umbennen, vorallem bei den Umlauten klappt es noch nicht so wie gewünscht (...)
Der Button "Leerzeichen" ersetzt Leerzeichen durch Unterstriche.
Der Button "Umlaute" ersetzt Umlaute (d.h. z.B. ä -> ae, ö -> oe usw. aber nicht umgekehrt)
Ansonsten: Sieh Dir bitte Menü: Bearbeiten -> Einstellungen -> Umbenennen an. Da kann man noch etwas in Sachen Umbenennen einstellen.
Hallo,
ich nutze die neueste "...dev-git"-Version unter Manjaro und bei mir ist nach dem Schneiden der Ton um wenige Sekunden versetzt.
Dies tritt nur bei HD-Dateien auf.
Ich habe so ziemlich alles ausprobiert, auch den Patch und habe heute auch mal alles, was zur OTR-Verwaltung gehört, gelöscht und komplett neu installiert.
Da es bei anderen scheinbar keine Probleme gibt, wäre ich für Hilfe sehr dankbar.
Viele Grüße
Anubis
Ok, dann war das (wieder einmal) ein Denkfehler von mir.
Jedoch stellt sich mir an dieser Stelle die Frage nach dem Sinn und Zweck der Umbenennung in diese Richtung:
Ö, Ä, Ü
Werden ja stets im Namen der Datei umgewandelt (oe,ae,ue) dargestellt. Ich persönlich habe mich um Dubletten zu vermeiden darauf festgelegt, diese immer händisch umzubenennen.
Deshalb dachte ich diese Umlautfunktion würde mir dieses Geschäft jetzt abnehmen...
Vielleicht wäre das ja eine neue sinnvolle Funktion in beide Richtungen umzuwandeln. :)
Mir stellt sich da keine Frage: Ä Ö Ü - das sind Sonderzeichen, mit denen hat man eigentlich grundsätzlich Ärger.
Ich stelle mir da einen externen Datenträgern vor, auf denen Dateien mit diesen Sonderzeichen liegen. Wenn die dann an andere Betriebssysteme (PC oder ggf. sogar TV-Geräte) gehängt werden - das kann wirklich drollig werden.
Von daher macht es ganz viel Sinn, die zu entfernen - und dann so komfortabel, ist doch super!
Viele Grüße
Nemo
@Anubis357:
Stelle bitte sicher, dass Du unter Menü: Bearbeiten -> Einstellungen -> Schneiden -> Kodierer: ffmpeg eingestellt hast. Und ich gehe davon aus, dass Du die avi.Datei nicht vor dem Schneiden in ein mkv umgewandelt hast.
Mehr fällt mir im Moment nicht ein.
@All: Hat sonst noch jemand das Problem?
Ich habe mir die letzte development als ZIP auf den Raspberry Pi heruntergeladen (keine DEBIAN-Installation geplant) und bekomme die gleiche Fehlermeldung, wenn ich das Programm starte:
Edit: Irgendwas in der Datei cutlists.py ist defekt. Wenn ich sie in IdleX lade und "check module" ausführe, kriege ich einen Syntax Error (gleich in der ersten Zeile, aber das ist Quatsch. Wenn ich die lösche, kommt der Fehler in der nächsten Zeile).Code:Traceback (most recent call last):
File "./otrverwaltung3p", line 111, in <module>
from otrverwaltung3p.actions import actions
File "/home/pi/otr-verwaltung3p-development/otrverwaltung3p/actions/actions.py", line 18, in <module>
from otrverwaltung3p.actions import decodeorcut
File "/home/pi/otr-verwaltung3p-development/otrverwaltung3p/actions/decodeorcut.py", line 31, in <module>
from otrverwaltung3p import cutlists as cutlists_management
File "<fstring>", line 1
(response = )
^
SyntaxError: invalid syntax
@guenni: In otrverwaltung3p/cutlists.py Zeile 123: self.log.debug(f"{response = }") bitte auskommentieren. Ist es das? Welche python-version läuft bei DIr?
@gilbert: Auch hier gefragt: Welche python-version läuft bei DIr?
@gilbert: Sorry. Bitte die Ausgabe von: python3 --version
Edit: Ich sehe gerade das es ein Ubuntu 18.04 Derivat ist. Also Python3.6.x
Scheint als ob die Syntax f"{variable = }" in dieser Python-Version noch nicht implementiert ist. Es liegt also an allen Vorkommen von: self.log.debug(f"{<irgendeine Variable> = }"). Wobei statt debug auch info, warning oder error vorkommen können.
@gilbert: Benutze bitte eine VM mit einem aktuellen Linux. Bei (L)Ubuntu wäre das 20.04 LTS. Besser noch ein Archlinux-Derivat.
Edit @guenni: Es betrifft tatsächlich nur cutlists.py:Wenn Du diese Zeilen auskommentierst sollte es funktionieren.Code:$: ag 'self\.log\..*\(f"{.* = }.*'
otrverwaltung3p/cutlists.py
123: self.log.debug(f"{response = }")
124: self.log.debug(f"{response.text = }")
140: self.log.debug(f"{video_filename = }")
Du hattest recht!Code:$ python3 --version
Python 3.6.9
Grund dass ich dieses Derivat verwende ist das bescheidene Parallells. Dieses schafft leider nur mit ZorinOS 15.2 den Coherence Mode, frag mich nicht warum bei den anderen nicht. In diesem Modus läuft nur sichtbar das OTRVerwaltungs-Fenster. Übrigens funktionierte die 1.00b7 samt Patch bestens darauf :-|
Vielleicht liegt es ja nur an einer Kleinigkeit ... :rolleyes:
Liebe OTR-Verwaltung3Plus Disktutanten und -innen,
ich bitte um Entschuldigung, wenn ich diesen Thread für ein "anderes" Thema nutze (und das auch noch als MOD! :eek:), aber ich hab da ein echtes Problem an der Backe, von dem ich glaube, dass ihr mit einer Antwort lösen könnt (und ich erreiche genau euch genau hier).
Immer mehr Linuxer unter uns beklagen sich, dass sie aufgrund veralteter Bibliotheksanforderungen im Standard-Decoder nicht mehr decodieren können. Ich bin leider kein Programmierer und habe im entsprechenden Thread schon mein Pulver verschossen, ohne geholfen zu haben.
Bei OTR gibt es zurzeit personelle Veränderungen, wie ihr sicherlich auch schon gemerkt habt, und just die Linux-Programmier-Abteilung ist derzeit echt schwer zu erreichen. Daher meine Frage an euch: hat jemand von euch Probleme mit dem Decodieren mit OTRVerwaltung3Plus? Ich selbst nutze sie unter akutellem OpenSuse problemlos, es sind wohl hauptsächlich Ubuntu-Menschen mit dem Problem.
Für eine oder zwei Antworten, gerne auch in der SB, bin ich sehr dankbar, ich möchte den Thread nicht kapern. Wenn es mehr werden sollte, werde ich mir erlauben, die entsprechenden Posts auszulagern.
Dankeschön! Und pflegt eure Pinguine gut. :D
@PeGu:
Mit otrv3p wird seit geraumer Zeit nur noch der easydecoder (cli!) ausgeliefert und ich habe bisher keine Bug-Reports erhalten. Ich kann erinnern, dass der Standard-Dekoder zumindest unter Manjaro "damals" SEGFAULTs erzeugt hat.
Der Thread, auf den Du Dich beziehst, betrifft allein die "Nicht-Funktionalität" der QT-GUI-Variante des Easydecoders (NICHT den Standard-Decoder).
https://www.otrforum.com/showthread....l=1#post419576 Sollte dies beantworten.
Für weitere Fragen stehe ich gern zur Verfügung :)
@loretotr
Vielen Dank! :D
In den von dir verlinkten Thread gehört das ganze auch eigentlich. ;)
(Danke fürs Verständnis; und ich hoffe, die Linux-Seite wird bald auch offiziell wieder agiler...)
Python(3) Version ist 3.7.3.
Ich habe das letzte Komma im Aufruf response = requests.post(... entfernt und mußte alle self.log.debug(f"... auskommentieren. Dann ist es endlich gestartet.
Ich war vor allem am Schneiden mit ffmpeg interessiert, weil es da mit x264 in rpiotrtool bestimmte (seltene) Problem gab. Dieser Fehler war jetzt mit ffmpeg-Schnitt nicht zu sehen (am Anfang der Datei), aber das Ende stimmte dafür überhaupt nicht (viel zu lang).
<Link entfernt>, da neuerer Link verfügbar (s. unten)
Fixt die Verwendung von zu aktueller f-string Syntax (cutlists.py)
Da ich im Wiki schrieb das otrv ab Python 3.6 läuft, soll es auch so sein. Ich bitte um Entschuldigung. Ich habe dieses Paket unter Ubuntu 18.04 getestet (Installation und das Schneiden einer HQ Datei) und es funktioniert so weit.
Dieses Paket benötigt man nur, wenn man Python 3.6 oder 3.7 nutzt.
@gilbert: Ich hoffe, Du hast Dein ZorinOS noch nicht eingestampft. otrv sollte jetzt darauf laufen.
Das ist definitiv nicht zutreffend. Bedenke bitte, das ich der Entwicker der otrv bin und mich daher gut mit den Interna des Programmes auskenne (oder auskennen sollte :D). Daher supporte ich hier.
Edit:
Neue Version:
otr-verwaltung3p-dev-1.0.0b8.post1-1.deb
Behebt Fehler im Smartrendering des neuen HD-Formates (Audio-Versatz und andere Fehler beim Schneiden).
Edit 2020-07-23 20:25
Bekannte Fehler in otr-verwaltung3p-dev-1.0.0b8.post1-1.deb:
Der Versuch VirtualDub (a.k.a. vdub) zu verwenden generiert einen Fehler ähnlich: "Wine nicht gefunden"
Dies ist für die AUR-Pakete behoben, Debian/Ubuntu müssen warten. vdub sollte nicht mehr benötigt werden
Vielen Dank für Deine Geduld :rolleyes:Zitat:
Das ist definitiv nicht zutreffend. Bedenke bitte, das ich der Entwicker der otrv bin und mich daher gut mit den Interna des Programmes auskenne (oder auskennen sollte ). Daher supporte ich hier.
Gerade schießt mir noch so eine andere Idee durch den Kopf:
Die Settings werden doch regelmäßig in einer Config-Datei gesichert und abgelegt.
1. Wie findest Du die Idee das Programm mit einer Export-/Importfunktion dieser Settings zu versehen, spart einem bei Neuinstallation die Eintragungen, Programmpfade, Speicherorte händisch zu suchen und einzutragen.
2. Zum Zusatzpaket vdub/wine wäre zugleich eine Importfunktion zu den jeweiligen Programmpfaden in dieser Config-Datei bequem und für Rookies eine massive Erleichterung :)
@loretotr/gcurse:
Ich habe bei mir mal verschiedene Versionen deiner otrv3p auf dem Raspberry Pi installiert. Es funktioniert nur in Teilen (dekdodieren und Cutinterface funktionieren nicht), aber mir kam es auf das Schneiden an und das funktioniert. Ähnlich wie du suche ich immer noch nach Optimierungen beim neuen HD-Format. Ich habe gesehen, daß du mit verschiedenen Offsets experimentiert hast, finde das Ergebnis aber sehr unbefriedingend, weil das Scheiden damit nicht mehr exakt an den in der Cutlist vorgeschriebenen Stellen passiert. Das kann ich an den Ergebnissen deutlich sehen, wenn ich sie mit rpiotrtool-Schnitten vergleiche.
Wie du vielleicht weißt, verwende ich in rpiotrtool inzwischen nur noch x264 für das Rekodieren der kleinen Schnipsel. Das funktioniert auch mit dem neuen HD-Format sehr gut, aber bei ca. 5% der Dateien kommt es zu kleinen Fehlern: An der Schnittstelle tauchen plötzlich ältere Frames auf, die dort nichts zu suchen haben. Da es sich um eine Art "Dreckeffekt" handelt, der nur sehr sporadisch auftritt, ist die Ursache bzw. eine Abhilfe aber nur schwer zu finden. Gestern ist mir aber nun ein Durchbruch gelungen. Dazu muß ich etwas ausholen.
Auf dem Raspberry Pi gibt es (standardmäßig) nur drei hardwarebeschleunigte Videoplayer: VLC, omxplayer(GUI) und Kodi. VLC hat mit den Original-OTR-AVIs (HQ und HD) beim Abspielen Probleme (es "ruckelt", weil viele Frames fehlen). Konvertiere ich die Datei aber nach MKV, werden die Videos perfekt abgespielt. In omxplayerGUI lassen sich die OTR-Dateien (HQ, HD) zwar perfekt abspielen, aber wenn man vorwärts oder rückwärtsspringt, gibt es kleine Ruckler. Das sieht man besonders schön bei stark reduzierter Abspielgeschwindigkeit, die ich beim manuellen Schneiden mit omxplayerGUI verwende: das Bild springt nach dem Springen ein paar mal vor und zurück, bevor es sich beruhigt. Auch dieser Effekt verschwindet, wenn ich eine MKV-Kopie der OTR-Datei benutze. Es liegt also am Containerformat (Audio- und Videostreams bleiben ja unverändert) und am jeweiligen Demuxer, ob diese Probleme auftreten oder nicht. (omxplayer verwendet übrigens ffmpeg als Demuxer.) Ich hatte deshalb schon von Anfang an in rpiotrtool die Option eingebaut, von den OTR-Dateien MKV-Kopien herzustellen. Diese werden dann z. B. bei der Schnittvorschau automatisch verwendet (wenn sie vorhanden sind). Das war auch als Hilfe für User gedacht, die sich die ungeschnittenen Videos mit VLC (ist nun der Standardplayer) anschauen möchten.
Nun hatte ich gestern die "Erleuchtung": vielleicht kommt ja auch der in x264 integrierte Demuxer (ffms) manchmal mit dem OTR-AVI-Format nicht klar? Dann habe ich in die Schnittroutine eingebaut, daß beim Vorhandensein einer MKV-Kopie diese als Quelle verwendet wird statt der AVI-Datei. Damit habe ich dann eine problematische Datei (die ich mir samt Cutlist extra aufgehoben hatte) geschnitten und siehe da: Ohne MKV-Kopie blitzt ein falscher Frame am Beginn des Schnitts auf, mit MKV-Kopie ist der Schnitt perfekt. Das ganze ist absolut reproduzierbar. Wie es sich bei FFMPEG verhält, kann ich nicht testen, weil ich es nicht mehr verwende (außer für das alte AVI-Format).
Um die Programmlogik nicht durcheinanderzubringen, setze ich den Wechsel auf das MKV-Format erst recht spät an: Unmittelbar vor der Kommentarzeile:
# video part 3 - encode small parts - smart rendering part (1/2)
wird "filename" auf die MKV-Kopie gesetzt (sofern vorhanden). Diese wird dann also nur noch für das Erstellen der neu kodierten Schnipsel und für das Herausschneiden der großen Blöcke genutzt.
Um den User nicht zu zwingen, alle Dateien nach MKV zu konvertieren, habe ich nun in rpiotrtool eingebaut, daß beim Erkennen des neuen HD-Formates automatisch eine solche MKV-Kopie erzeugt wird. Dann dauert das Schneiden zwar ein bißchen länger, aber wenn es dann fehlerfrei ist, spielt das wohl keine Rolle. Und die Schnitte werden exakt da gesetzt, wo es die Cutlist vorgibt und nicht durch irgendwelche Offsets manipuliert.
Das wollte ich dir mal als Anregung für die Otrverwaltung3p geben. Vielleicht kannst du es ja mal selber testen. Ich habe es selber in otrv3p auf dem RPi mal probiert mit der gleichen MKV-Datei und x264, aber irgendwas stimmt hier beim Schneiden nicht. Am Ende erscheint ein Teil, der gar nicht erscheinen dürfte und der Ton ist komplett asynchron. Vielleicht hängt das ja auch wieder mit der Python3-Version zusammen. In rpiotrtool wird die gleiche Datei perfekt geschnitten und der Ton ist auch synchron.
Nachtrag: Ich habe das jetzt mal in die Version 1.0.0.b4 aus dem gcurse repository reingepatcht und da funktioniert das Schneiden (mit x264) genau wie mit rpiotrtool: ohne MKV-Kopie mit dem Fehler beim ersten Schnitt und mit MKV-Kopie ohne den Fehler. Auch das Ende stimmt hier und der Ton ist synchron.
ich habe mal otr-verwaltung3p-dev-1.0.0b8-2 ausprobiert, im Gegensatz von otr-verwaltung3p-dev-1.0.0b8.post1-1.deb läuft diese Version auf ZorinOS aka Ubuntu 18.04 nicht:
Code:otrverwaltung3p
Traceback (most recent call last):
File "/usr/bin/otrverwaltung3p", line 114, in <module>
from otrverwaltung3p.actions import actions
File "/usr/lib/python3/dist-packages/otrverwaltung3p/actions/actions.py", line 17, in <module>
from otrverwaltung3p.actions import decodeorcut
File "/usr/lib/python3/dist-packages/otrverwaltung3p/actions/decodeorcut.py", line 30, in <module>
from otrverwaltung3p.conclusions import FileConclusion
File "/usr/lib/python3/dist-packages/otrverwaltung3p/conclusions.py", line 21, in <module>
from otrverwaltung3p.cutlists import Cutlist
File "<fstring>", line 1
(response = )
^
SyntaxError: invalid syntax
@MACMUPPET; Bein Zusammenführen hast du sämtliche deutschen Sonderzeichen (ä,ö,ü,ß) vermurkst.
@gilbert:
otr-verwaltung3p-dev-1.0.0b8-2.deb ist das 2. Paket der otr-verwaltung3p Version 1.0.0b8. Und 1.0.0b8 ist älter als 1.0.0b8.post1. Die Zahl nach dem letztem Bindestrich bezieht sich auf das deb-Paket und gehört nicht zur Versionsnummer der otr-verwaltung3p. Siehe https://github.com/EinApfelBaum/otr-...ung3p/releases: Die neueste Version steht immer oben.
@guenni:
Die otrv schneidet nur noch mit ffmpeg, da x264, warum auch immer, bei mir nicht korrekt schneidet. Ffmpeg ist mir auch lieber, da das Archlinux x264 ohne den ffms-Demuxer ausgeliefert wird.
Falls Du noch mit otrv experimentieren möchtest, bitte immer die neueste Version benutzen. Am besten
Diese Methode erspart den Download von ca. 250 Mb überflüssiger git history. Das kannst Du dann jederzeit mit git pull aktualisieren.Code:git clone --branch development --single-branch --shallow-since=2020-02-14 https://github.com/EinApfelBaum/otr-verwaltung3p.git
@loretotr:
OK, danke für den Tip.
Wenn du nur noch mit ffmpeg schneidest, hast du dann immer noch gelegentlich Probleme mit dem neuen HD-Format? Ich dachte, du hättest sowas erwähnt.
@guenni: Bisher nicht. Aber ich schneide auch sehr selten HDs.
ich habe weiter herumexperimentiert und bin auf eine für OR-Verwaltung unlösbare aufgabe gestossen
https://otrkeyfinder.com/de/?search=....HQ.avi.otrkey lässt sich definitiv nicht damit schneiden, es kommt immer zum Abbruch mit der Meldung 'kodier Fehler'.
Mit Coldcut unter Windows klappt's :confused:
Darf ich mich nochmal als völliger DAU hier zwischendrängen?
Ich habe das Programm auf meinem alten Rechner vor gut einem Jahr schon mal zum Laufen bekommen und war damit auch sehr zufrieden, jetzt probiere ich es auf meinem neuen Rechner seit gestern Abend wieder, aber ich scheitere. Vorallem auch daran dass ich nach wie vor keine Ahnung von Linux habe und schon einfachste Anweisungen nicht verstehe.
Ich habe einen neuen Rechner auf dem Ubuntu 20.04 vorinstalliert ist. Ich habe keine Ahnung, was an "Bibliotheken" (was auch immer das ist) vorinstalliert ist und weiß auch nicht, wie ich das herausfinden kann.
Ich bin in der Lage das Terminal zu öffnen und dort Befehle einzugeben (und manchmal verstehe ich auch, was ich da tippe)
Daher meine Frage, gibt es eine leichtfassbare Anleitung für Newbies,
- welche Voraussetzungen mein System erfüllen muss und wie ich herausfinde, ob das auf meinem System schon vorhanden ist
- wie ich die OTRVerwaltung zum laufen kriege.
Und bitte lieber einen Schritt zu viel erklären als einen zu wenig.
Ich habe die otr-verwaltung3p-3.2.5-A.tar.gz herunter geladen und entpackt, sie liegt jetzt in einem Verzeichnis, dass ich OTR genannt habe. Wenn ich jetzt aber dort in bin gehe und dort die otrverwaltung doppeltklicke, denn öffnet sich nur ein Editor mit Text, aber es passiert nichts.
Liebe Grüße
Pormethea
Herzlichen Dank, dass du dich meiner annimmst.
Ich habe die Datei runtergeladen, ich habe sie entpackt und dann die beiden xz-Dateien ebenfalls entpackt, alle Dateien liegen jetzt in einem Verzeichnis, das otr heißt.
Ich gehe in /use/bin und mache einen Doppelklick auf otrverwaltung3p und es erscheint ein rundes Ding, dass sich dreht (dafür gibt es sicher einen professionelleren Namen) und dann passiert exakt nichts.
Ich hatte noch vergessen zu erwähnen, dass ich Ubuntu 20.04 verwende.
Beim Vorgänger 18.04 gab es in "Ubuntu Programme" eine Möglichkeit von dort auf das Programm zuzugreifen und es zu installieren.
Diese Funktion heißt offenbar jetzt "Discover" und dort finde ich nichts, wenn ich OTR eingebe.
Hallo promethea,
Versuche es einmal mit einem Doppelklick auf die .deb-Datei. Dann sollte sich eigentlich ein Programm öffnen, mit dem Du otrv3p installieren kannst.
Edit: Ok, Doppelklick öffnet einen Entpacker :(
Also: Bitte Rechtsklick auf die deb-Datei, dann etwas wie "Öffnen mit ..." klicken und dann entweder "Discover" oder etwas wie "Software installieren" wählen/klicken.
Super herzlichen Dank, das war die Lösung.
Bei Doppelklick hat sich die Datei ja nur entpackt, aber aufgrund deines Hinweises habe ich mit rechts angeklickt und "Discover" als ausführendes Programm angegeben und schon hat es funktioniert.
Ich habe mit der letzten Version versucht einen topaktuellen HD-Film zu schneiden und stoße auf den selben Fehler wie im August, vielleicht könnte sich loretotr
mal die Sache anschauen :rolleyes:
Screenshot
herzlichen Dank!
hier noch der Link zur Datei :rolleyes: