Ich hatte den Bedarf, mit VLC Streaming einer DVB-C-Quelle einzurichten.
Das habe ich vor laaanger Zeit schon einmal getan und hat damals(TM)
auch problemlos funktioniert (war irgendeine 1.x-Version).
Mit V2.2.2 hingegen habe ich schon fast einen ganzen Tag damit
zugebracht und bin zu keinem Ergebnis gekommen. Was problemlos
funktioniert, ist das reine lokale Abspielen der DVB-C-Quelle, z.B.:
/usr/bin/vlc dvb-c://frequency=450000000 :dvb-srate=6900000
:dvb-ts-id=1079 :dvb-modulation=256QAM :program=28011 :meta-title="rbb
Berlin HD"
Aber sobald ich :sout="Ausgabekette" hinzufüge, geht garnix mehr.
Nichtmal mit der einfachsten denkbaren Ausgabe-Chain, die schlicht exakt
dasselbe tun sollte, was auch die Ausgabe ohne explizite Spezifikation
einer Ausgabekette tut, nämlich:
/usr/bin/vlc dvb-c://frequency=450000000 :dvb-srate=6900000
:dvb-ts-id=1079 :dvb-modulation=256QAM :program=28011 :meta-title="rbb
Berlin HD" :sout="#display"
VLC akzeptiert die Parameter, wirft keinerlei Fehler, captured
offensichtlich auch den Input, liefert aber rein garnix an die Ausgabe.
Was haben die Typen da wieder kaputtgefrickelt? Gibt's einen Workaround?
Ma W. schrieb:> c-hater schrieb:>> kaputtgefrickelt>> Geht es auch sachlich?
Das war sachlich. Hätte ich meinen ganzen Frust in mein Posting
einfliessen lassen, wäre es allerdings wirklich sehr unsachlich
geworden...
Hier geht es offensichtlich wohl um einen Bug, der VLC von der
überwiegenden Mehrzahl der Features trennt, die VLC nachweislich schon
einmal hatte.
Welche andere Ausdruck als "kaputtgefrickelt" wäre denn deiner Meinung
nach dieser Sachlage angemessen?
Probiere es mal mit Version 2.0.8; das ist die letzte Version, die
diesbezüglich nicht kaputtgefrickelt ist. Mit neueren Version bekomme
ich gar nichts mehr zum Laufen, nicht einmal simples DLNA-Streaming vom
TV-Receiver (DVB-C). Ich dachte erst, dass ich nur zu blöd wäre, aber
zig Beiträge über diese Probleme in verschiedenen Foren haben mich eines
Besseren belehrt.
BTW: Gehört eigentlich nach "PC Hard- und Software".
Hannes schrieb:> Probiere es mal mit Version 2.0.8; das ist die letzte Version, die> diesbezüglich nicht kaputtgefrickelt ist. Mit neueren Version bekomme> ich gar nichts mehr zum Laufen, nicht einmal simples DLNA-Streaming vom> TV-Receiver (DVB-C). Ich dachte erst, dass ich nur zu blöd wäre, aber> zig Beiträge über diese Probleme in verschiedenen Foren haben mich eines> Besseren belehrt.>> BTW: Gehört eigentlich nach "PC Hard- und Software".
Agree. Ich hatte mich einfach nur "verklickt". Vielleicht ist ja einer
der Moderatoren gnädig und verschiebt den Thread dorthin.
Bitte.
Hannes schrieb:> Probiere es mal mit Version 2.0.8; das ist die letzte Version, die> diesbezüglich nicht kaputtgefrickelt ist.
Scheint nicht so.
Ich habe für die Tests auf Windows7(x64) gewechselt, weil es da viel
einfacher ist, mal eben die VLC-Version zu wechseln als in einer
Linux-Umgebung. Das musste ich sehr leidvoll bei dem Versuch erfahren,
ein VLC 2.0.8 in einer aktuellen Linux-Umgebung kompilieren zu wollen...
However: Nachdem ich Windows7(x64) erstmal dazu überredet hatte,
überhaupt DVB-C zu unterstützen (was es von Hause aus aus unerfindlichen
Gründen nicht tut, obwohl es das problemlos könnte, es fehlen nur ein
paar Einträge in der Registry), habe ich nun die freie Auswahl aus allen
64Bit-VLC-Versionen.
Also habe ich angefangen zu testen und bin jetzt bei VLC-Version 2.1.0.
Die funktioniert auf jeden Fall noch vollständig bezüglich ":sout=#..."
Ich bin sehr gespannt, wie es weitergeht, habe allerdings erst im im
nächsten Jahr Zeit, die Sache weiter zu verfolgen. Mein akutes Problem
ist jedenfalls erstmal gelöst. Ich hab' endlich meinen DVB-C-Stream. :o)
Das, was ich ausserdem noch brauche, kann ich unter Windows genauso
leicht runterprogrammieren wie unter Linux. Also wähle ich erstmal
Windows als Host für meine Anwendung.
Statt hier über VLC und linux herzuziehen und Windows Werbung zu machen
köntest du auch etwas sinvolles machen können, wie z.B. einen Bug im
Bugtracker von VLC erfassen: https://trac.videolan.org/vlc/
Daniel A. schrieb:> Statt hier über VLC und linux herzuziehen und Windows Werbung zu machen> köntest du auch etwas sinvolles machen können, wie z.B. einen Bug im> Bugtracker von VLC erfassen: https://trac.videolan.org/vlc/
Du hast meine Postings offensichtlich nur sehr oberflächlich gelesen
oder deine intellektuellen Fähigkeiten genügen nicht, um deren Bedeutung
korrekt einschätzen zu können...
Insbesondere scheint dir das Fragezeichen am Ende des Subjects dieses
Threads entgangen zu sein...
Und was den Bugreport betrifft: Sobald ich im nächsten Jahr die
Versionen bis zum dann aktuellen Stand durchgecheckt haben werde, werde
ich (vielleicht) einen sehr konkreten Bugreport liefern können. Im
Moment weiss ich ja noch nicht einmal, bei welcher Version der Bruch
stattfand oder ob überhaupt ein Bruch stattfand, oder ob VLC eventuell
nur in der Linux-Variante oder gar nur in meiner Linux-Distribution
kaputtgefrickelt wurde, oder ob eventuell sogar nur ein Bruch der
Kompatibilität bei den Kommandozeilenoptionen (und somit am Ende nur die
lausige, weil generell völlig veraltete Doku) Schuld ist.
Das Einzige, was derzeit absolut sicher ist, ist: ":sout=#..."
funktioniert nicht unter Linux Mint Mate x64 in der aktuellen Version
mit der dafür aktuellen VLC-Version *und*: Es funktioniert aber in der
x64-Umgebung von Windows7 mit der VLC(x64)-Version 2.0.7 und 2.1.0,
ausserdem auch unter WindowsXP (32bit) mit VLC(x86) 2.0.7, 2.0.8 und
2.1.0.
Dieses sichere Wissen genügt aber definitiv noch nicht für einen
sinnvollen Bugreport, der irgendwem irgendwie wirklich hilft...
So ein Bugreport wäre Lamer-Scheisse, das landet in der
OpenSource-Gemeinde sowieso meist nur im Lokus, da kümmert sich i.d.R.
kein Schwein ernsthaft drum. In der kommerziellen Softwareerstellung
muss man sich leider auch um sowas kümmern, deswegen weiss ich, wie
nervig das ist und mag die VLC-Entwickler deswegen auch nicht mit sowas
behelligen.
Du kannst aber sicher sein: Wenn ich das Problem gefunden habe (und ich
bin absolut sicher, dass ich es finden werde und auch die
Verantwortlichen dafür), dann werde ich genau diesen Verantwortlichen
einen Bugreport zukommen lassen, der nichts an Deutlichkeit und
Konkretheit vermissen lassen wird...
Das ursprüngliche Ziel meines Postings war übrigens (auch das hast du
nicht erkannt): Die Sache mit der lausigen Dokumentation als mögliche
Ursache des Problems auszuschliessen. Ich hatte gehofft, dass irgendwer
irgendwas in der Art postet: "Du musst seit Version X.Y.Z nicht mehr
schreiben :sout=#..., sondern statt dessen..."
Denn das ist eine, angesichts der Historie von VLC mit einem Haufen von
(meist unnötigen) Kompatibilitätsbrüchen, sehr wahrscheinliche Ursache
für mein Problem...
c-hater schrieb:> Du hast meine Postings offensichtlich nur sehr oberflächlich gelesen> oder deine intellektuellen Fähigkeiten genügen nicht, um deren Bedeutung> korrekt einschätzen zu können...
Ist dir bewusst, dass du hier voreilige Schlüsse ziehst, und dies eine
Beleidigung war?
> Insbesondere scheint dir das Fragezeichen am Ende des Subjects dieses> Threads entgangen zu sein...
Ich schreibe keine Antworten, die sich nur auf den Titel eines Threads
beziehen. Du bist vermutlich Opfer des sogenannten "self-serving bias"
geworden. Sorry falls mein Kommentar im letzten Beitrag etwas zu
Provokativ für dich war, es war nicht böse gemeint.
Falls du dich wunderst, worauf genau ich mich bezogen hatte, es ging um
2 Abschnitte. Der Satz:
> Was haben die Typen da wieder kaputtgefrickelt?
Hat eine negative Konnotation. Zudem implizierst du mit "wieder", dass
das nichts ungewönliches ist, häufiger, oder schonmal vorgekommen ist.
Das problem ist nicht die Aussage, dass es kaputtgefrickelt wurde,
sondern das es erneut geschehen ist. Dies kann so aufgefasst werden,
dass VLC nicht besonders gut wäre, und wird bei anderen, die VLC noch
nicht kennen, unterbewust zu schlechteren erwartung führen, wodurch
diesen dann VLC effektiv schlechter vorkommen wird.
Das andere war der Abschnitt:
> Das, was ich ausserdem noch brauche, kann ich unter Windows genauso> leicht runterprogrammieren wie unter Linux. Also wähle ich erstmal> Windows als Host für meine Anwendung.
Der Abschnitt brigt rein garkeine relevante Information, es ist schlicht
irrelevant ob du planst das OS zukünftig zu wechseln oder nicht. Du
implizierst aber, dass Linux unnötig und Windows zu bevorzugen ist.
Rückblickend unter dem Vier-Seiten-Modell betrachtet war das ganze wohl
ein Missverständnis, es ist deshalb nicht sinvoll zu versuchen zu
argumentieren, bei wem der Fehler liegt. [1]
> Dieses sichere Wissen genügt aber definitiv noch nicht für einen> sinnvollen Bugreport, der irgendwem irgendwie wirklich hilft...>> So ein Bugreport wäre Lamer-Scheisse, das landet in der> OpenSource-Gemeinde sowieso meist nur im Lokus, da kümmert sich i.d.R.> kein Schwein ernsthaft drum.
Ich habe diesbezüglich gute Erfahrungen mit OpenSource Projekten
gemacht. Obwohl, kleinere Projekte scheinen häufig schneller und
zuverlässiger zu reagieren. Entwickler haben häufig auch bessere
Methoden, um relevante Änderungen einzuschränken, dank
Versionskontrolle, bei der man nachsehen kann wer was in welchen Dateien
zwischen welchen Versionen geändert hat.
> Du kannst aber sicher sein: Wenn ich das Problem gefunden habe (und ich> bin absolut sicher, dass ich es finden werde und auch die> Verantwortlichen dafür), dann werde ich genau diesen Verantwortlichen> einen Bugreport zukommen lassen, der nichts an Deutlichkeit und> Konkretheit vermissen lassen wird...
Sehr gut. Aber schraube die Deutlichkeit eventuell etwas runter und
ersetze sie durch Vollständigkeit. Andernfalls bekommt man deutliche
Antworten zurück.
Beim durchprobieren kann man die durchschnittleiche Dauer reduzieren,
indem man jedes mal die Möglichkeiten halbiert. Falls es z.B. Version 18
ist, und man weiss es ist in Version 100 aber nicht in Version 1, kann
man es in der Reihenvolge probieren: 50 -> 25 -> 12 -> 18
> Das ursprüngliche Ziel meines Postings war übrigens (auch das hast du> nicht erkannt): Die Sache mit der lausigen Dokumentation als mögliche> Ursache des Problems auszuschliessen. Ich hatte gehofft, dass irgendwer> irgendwas in der Art postet: "Du musst seit Version X.Y.Z nicht mehr> schreiben :sout=#..., sondern statt dessen..."
Na dann schreib das doch. Man hätte etwas in die richtung "Ist das ein
Bug oder gab es eine Änderung?" schreiben können, statt "Was haben die
Typen da wieder kaputtgefrickelt?". Letzteres beinhaltet die Möglichkeit
eines eigenen fehlers nähmlich nicht.
Es gibt situationen, in denen Konnotationen sinvoll sind, man muss dann
aber auch mit den Reaktionen anderer umzugehen wissen.
1)
https://de.wikipedia.org/wiki/Vier-Seiten-Modell#Beispiel_f.C3.BCr_eine_durch_Missverst.C3.A4ndnisse_gest.C3.B6rte_Kommunikation
Ich bin VLC Nutzer und Fan. Und nachdem ich mir mal den Source Code,
Build, Dokumentation (Wiki) und Support im Forum angeschaut habe, bin
ich echt erstaunt darüber, dass VLC vergleichsweise stabil läuft
(Kernfunktionen).
Allein schon einen statischen Build hinzubekommen, ist ein Problem. Ein
statischer Build ist aber Voraussetzung für eine Fehleranalyse,
insbesondere da VLC eine Vielzahl von Paketen nutzt.
VLC selbst unterstützt nur dynamische Builds. Für Linux gibt es jedoch
(auf Nachfrage) nicht ein Referenzsystem (also Distro + definierte
Packages + dyn. Build).
Dazu kommt, dass VLC eine Unmenge an Erweiterungen unterstützt, die
irgendwann mal eingebaut wurden (von Leuten die heute nicht mehr dabei
sind) und nicht mehr gepflegt werden. Während dessen wird an anderen
Fronten weiter entwickelt. Ohne Regression Tests ist es reine Glücksache
was noch funktioniert. Und wenn man in das Forum schaut, bekommt man
einen Eindruck.
Es mangelt einfach an Man Power für ein so umfangreiches Projekt. Daher
wäre es imho ratsam, VLC in Kern und Erweiterungen zu splitten. Nur laut
gedacht...