Posts by TEN


    ich hab mir die Quellen von inputlirc besorgt, und dann inputlircd übersetzt. Die zwei Zeilen hab ich im Code in der Funktion processevent() eingefügt, und in den Syslog getraced. Die eine Zeile oben, wo die ganzen Events reinkommen und noch alle Events zu sehen sind (auch die, die später gar nicht an VDR weitergeleitet werden (Misc und Syn)), die zweite Zeile unten, kurz bevor der Event an lircd weitergeleitet wird ...


    Damit kann ich genau nachverfolgen welche Events reinkommen (aka was die Fernbedienung liefert, und vom IR-Sensor auch erkannt wird), und welcher Teil davon an lircd weitergegeben wird ...


    Mit etwas Spielen an den Zeiten, hab ich dann Werte herausgefunden, mit denen Repeatkommandos an den lircd weitergegeben werden ...
    Ich hänge unten mal den Code ran, mit dem ich das getestet habe

    Danke, :] welches -r war es denn für inputlirc, und ggf. davor schon welche -D und -P für ir-keytable ?
    Kannst Du evtl. eine "Bauanleitung" aus Diff und Deiner Bash-History geben - oder lässt sich ein allgemeingültiger Bugfix ableiten, um zumindest inputlirc verlässlicher zu machen?
    Die Lage bei LIRC ist ja schon schlimm genug... :rolleyes: www.vdr-portal.de/board18-vdr-…-unter-ubuntu-16-04-2-lts

    Quote

    hier die Event´s die ich jetzt bekomme, in einer selbst generierten Version von inputlirc ...


    - Inputlircd info 1 ist oben im Inputlircd, wo die ganzen Event´s ankommen (Type 1=KEY, Type 4=MISC, Type 0=SYN)
    - Inputlircd info 2 ist unten im inputlircd, wo der Event Richtung über /var/run/lirc/lircd an VDR weitergegeben wird (1: Tastencode in Hex, 2: Repeat-Zähler, 3: Text String "Key_Code_" mit Tastencode dezimal angehängt; 4: Empfängerdevice)


    Man sieht schön, wie der Repeat-Zähler hochgezählt wird.

    Kannst Du uns verraten, wie und womit Du das aufgesetzt hast?

    Versuchen wir es also mal mit sudo apt install lirc, auf das devinput-Device, danach Reboot.


    /etc/lirc/hardware.conf


    ...und /etc/lirc/lircd.conf

    Code
    1. include /usr/share/lirc/remotes/devinput/lircd.conf.devinput



    Damit das Eventsystem und dadurch VDR die Tastendrücke sehen kann, ist schrägerweise erst mal sudo service lirc stop erforderlich.


    Dann aber regnet es (im Gegensatz zum vorigen Post) EV_MSCs für unbekannte und EV_KEYs für bereits definierte Tasten in sudo evtest bzw. sudo ir-keytable -t.


    Bei Verwendung des VDR X-Frontend werden die Tasten wieder mal doppelt erkannt, da automagisch als vdr-sxfe --lirc in die Menüs eingetragen (Jahre alter https://bugs.launchpad.net/ubu…ineliboutput/+bug/1001818 alle Releases wieder).


    Um zum Test dem aktuellen Ubuntu-VDR abzugewöhnen, (statt, oder schlimmer noch neben vdr-sxfe) selbst --lirc zu verwenden, ist diese Zeile wohl in /etc/vdr/conf.d/00-vdr.conf auszukommentieren:
    /etc/default/vdr ist leer und OPTIONS="--lirc=/dev/null" gemäß LIRC deaktivieren scheint darin nicht mehr zu funktionieren.
    Bei mir führt das allerdings auch nur dazu, dass die Tastendrücke statt doppelt beim VDR gar nicht mehr ankommen, trotz vdr-sxfe --lirc.


    Leider konnte ich bislang auch mit diversen Delays weder auf Ebene von ir-keytables noch von inputlircd die automatische Wiederholung gehaltener Tasten in VDR zum Laufen bringen:
    [gelöst] Probleme mit Debian Stretch und lircinput seit Debian 4.8.11 beschreibt ein ähnliches Problem, aber für die RC6-Fernbedienung.
    (Erst) nach(!) sudo service lirc stop erkennt irw gedrückt gehaltene Tasten, nur wie VDR ohne Wiederholung.
    Nach weiterem sudo service inputlirc stop wird /dev/input/event9 auch für sudo ir-keytable -t und sudo evtest zugänglich:
    Beide zeigen (anders als VDR&irw) funktionierende Wiederholung gedrückt gehaltener Tasten.

    Naja Zeile 16 und 17 aus Post 36 sagen doch aber, dass inputlircd noch auf /dev/input/event9 zugreift?


    Ok, du hast inputlircd zwar gekillt, dann aber den Rechner neu gestartet. Kann es sein, dass das inputlircd bei dir beim booten automatisch mit gestartet wird und sich dann die events wieder krallt?

    Ich habe beide Varianten (ohne und mit apt-Paket lirc) in IR an mceusb unter Ubuntu 16.04.2 LTS so detailliert wie nur möglich aufgedröselt, aber konnte noch nicht herausfinden, wo es klemmt.


    Eigentlich sollte ich ohne apt-Paket lirc auskommen, falls es zum nur darin enthaltenen irsend auch mit dem neueren Kernelansatz irgendein Pendant gibt.

    Da vom apt-Paket lirc abgeraten wird, erfolgt zunächst nur sudo apt install vdr vdr-plugin-femon vdr-plugin-xineliboutput inputlirc.


    /lib/udev/rules.d/60-ir-keytable.rules (in früheren Versionen noch Priorität 40) enthält

    Code
    1. ACTION=="add", SUBSYSTEM=="rc", RUN+="/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s $name"


    Universal8in1 folgenden Inhalts (unverändert wie am IR-Port der DVBsky angelernt, für auf Code 052 definierte AUX-Tasten) kommt weiterhin nach /lib/udev/rc_keymaps - obwohl in /etc/rc_maps.cfg immer noch falsch /etc/rc_keymaps steht.


    /etc/rc_maps.cfg wird folgende tabulatorgetrennte Zeile angefügt:

    Code
    1. mceusb * Universal8in1


    /var/lib/vdr/remote.conf (worauf ein bis dahin ungültiger Symlink aus /etc/vdr zeigt) erhält den Inhalt:




    Damit müsste doch alles an Ort und Stelle sein?! :rolleyes:


    Die Tasten sollen an VDR übergeben werden durch inputlircd -g -m 0 /dev/input/by-path/pci-0000:00:1d.0-usb-0:1.5:1.0-event (systemabhängig).


    sudo service inputlirc stop, um folgendes testen zu können, wie von http://www.lirc.org/html/configuration-guide.html verordnet:


    Direkt am Kernel werde ohne apt-Paket lirc werden also gar keine Tasten erkannt (und natürlich fehlt auch irsend).


    Dabei sollten selbst für unbekannte Fernbedienungen hier Scancodes erscheinen.


    Was aber funktioniert, ist folgendes:


    Das Problem muß also nach dem oberen Pfeil ---->---- von http://www.lirc.org/html/confi…l-configuration-decisions zwischen Kernel und Linux Input Layer liegen.



    Als letzte Zeile der /lib/udev/rules.d/60-ir-keytable.rules ist also erforderlich:
    ACTION=="add", SUBSYSTEM=="rc", RUN+="/usr/bin/ir-keytable -c -p sony -w /lib/udev/rc_keymaps/Universal8in1"
    Evtl. ergänzt um derzeit wohl nur manuell und mit einem Hack zu ermittelnde -D und -P, damit die Wiederholung gedrückt gehaltener Tasten auch für den VDR hinter inputlirc funktioniert.

    Naja Zeile 16 und 17 aus Post 36 sagen doch aber, dass inputlircd noch auf /dev/input/event9 zugreift?


    Ok, du hast inputlircd zwar gekillt, dann aber den Rechner neu gestartet. Kann es sein, dass das inputlircd bei dir beim booten automatisch mit gestartet wird und sich dann die events wieder krallt?

    Das hatte ich wohl etwas widersprüchlich gepostet:
    Klar autostartet inputlirc, dessen Prozess(e) habe ich aber zum Test jeweils gekillt,
    außerdem sogar sudo apt remove lirc angewendet und rebooted.
    D.h. nichts außer dem Kernel (evdev) selbst dürfte sich das mceusb krallen.
    Warum aber sehe ich dann gar keine Events?


    xorg sollte nicht stören, hatte aber sicherheitshalber auch dieses mal mit dem Ignore-Eintrag ferngehalten.


    In /etc/rc_maps.cfg habe ich auskommentiert:
    #* rc-rc6-mce rc6_mce
    Trotzdem sehe ich es überall noch (unten mit lirc, aber ohne ebenfalls):



    Dein Problem ist nicht der xserver, sondern inputlircd. Wenn du mit ir-keytable oder evtest spielen willst, musst du vorher inputlircd beenden.

    Fürs mceusb habe ich ja inputlircd gekillt und lirc sogar deinstalliert: Danach (nach Reboot) kommen keine events mehr an.
    Wird lirc mit dem System hochgefahren und dann beendet, erkennen ir-keytable und evtest die Tasten.
    Nur dann habe ich auch irsend.
    Muß ich, um ohne lirc auszukommen, das Modul rc_rc6_mce irgendwie loswerden, da die Fernbedienung ja keine RC6, sondern in /lib/udev/rc_keymaps/Universal8in1 definiert ist? :rolleyes:
    Habe diesen nicht T982-spezifischen Teil mal in http://www.vdr-portal.de/board…-unter-ubuntu-16-04-2-lts verlagert.

    Die Fernbedienung war in den letzten Jahren meist der komplizierteste und mit widersprüchlichster Dokumentation belastete Teil der VDR-Inbetriebnahme.

    Allerdings hänge ich an einer Stelle - wie immer bei so einem Update kämpfe ich mit Lirc.

    Scheint also nicht nur mir so zu gehen.


    Die Zusammenhänge aktuell dargestellt findet man allenfalls für eventlircd und wohl yaVDR unter https://docs.google.com/drawings/d/1LZj77h-AbbYpUapqITRFMyBs-xuwAXjwqyBTTgjvDk8/edit?authkey=CMzNqKoB&hl=de&pli=1 bzw. http://www.pro-linux.de/artike…n-lirc-mit-inputlirc.html.


    Aus DVBSky (Mystique TeCaBiX) LIRC ? ausgekoppelt versuche ich daher mal den aktuellen Stand der Dinge zusammenzuschreiben,
    um einen VDR der Distributionsstandardpakete des gerade erschienenen Ubuntu 16.04.2 LTS
    an einem gängigen HP-MediaCenter-USB-Modul (http://kodi.wiki/view/File:Hpremote.jpg) unter Kernel 4.8 fernbedienbar zu machen,
    mit einem Sender gemäß den beiden ersten 8in1-Dateien aus http://lirc.sourceforge.net/remotes/universal/:


    Grundfehler der meisten Anleitungen scheint mir der Vorschlag, (erst und nur) innerhalb eines bestimmten Protokolls und Keymappings testen zu wollen, ob überhaupt etwa empfangen wird.
    https://wiki.ubuntuusers.de/Ko…ote/#Fernbedienung-testen
    https://ubuntuforums.org/showthread.php?t=1754719
    http://kodi.wiki/view/HOW-TO:S…nux#Edit_the_driver_table
    So wird das meiste weggfiltert und damit nichts angezeigt, ohne dass man sehen könnte, ob die Sender und Empfänger an sich funktionieren und wo die Konfiguration noch bearbeitet werden muß.
    Startpunkt muß vielmehr die rohe Ausgabe von /dev/lirc0 sein, bei der Kernellösung rc-code z.B. mit sudo hexdump -C wie schon beim "klassischen" LIRC das Tool mode2.

    Richtig noch (auf älterem Stand): http://www.vdr-wiki.de/wiki/in…_LIRC_Installation#Testen
    Kaum eine Anleitung verdeutlicht zudem, dass und wie diese untere Ebene hierfür erst durch Beenden autogestarteter den Zugriff darüberliegend blockierender Programme freigelegt werden muß.


    Außerdem wird bis zum aktuellen Ubuntu-LTS ein uraltes apt-Paket lirc (0.9.0) ausgeliefert: Tickets zu Problemen, die dies verursacht, werden bei dieser und auch anderen Distributionen massenweise unter Verweis auf neuere Versionen (oder Konfiguration ohne diese zu bezeichnen, bis hin zum LIRC-Maintainer höchstselbst) geschlossen,
    https://bugzilla.redhat.com/show_bug.cgi?id=658628#c13
    https://bugs.launchpad.net/ubuntu/+source/lirc/+bug/783202#5
    https://bugs.launchpad.net/ubuntu/+source/lirc/+bug/1029604
    obwohl diese auch 2017 gar nicht in offiziellen Paketquellen sind:
    https://launchpad.net/ubuntu/+source/lirc
    https://launchpad.net/~leamas-…archive/ubuntu/lirc-0.9.4
    https://bugs.launchpad.net/ubuntu/+source/lirc/+bug/1443590


    Ohne apt-Paket lirc wird zunächst gar nichts erkannt, allerdings macht sich ein Tastendruck durch Ausgaben auf /dev/lirc0 bemerkbar (s.u.):
    Somit ist die Funktion der Fernbedienung belegt und man kann sich mittels Durchprobieren zum passenden Protokoll und Keytable vortasten:
    In meinem Falls führt sony zu einem fernbedienbaren VDR, wenn auch nach inputlirc noch ohne Tastenwiederholung.


    Mit apt-Paket lirc funktioniert zumindest nach sudo service lirc stop die Fernbedienung im VDR wenn auch ohne Tastenwiederholung.
    Es ist wohl weiterhin erforderlich, wenn man neben dem IR-Empfang auch noch senden muß, und macht alles noch wilder: https://ubuntuforums.org/showthread.php?t=2270362


    Hoffe es springt jemandem ins Auge, was in den folgenden Posts (ohne und mit apt-Paket lirc) fehlen könnte, damit ich das ergänzen kann.

    olebowie wrote:

    mir ist immer noch nicht klar warum ihr unbedingt lirc benutzen wollt


    Wie hindert man (bei Deinem Ansatz ohne LIRC zu laden) Xorg (bzw. acpid) daran, das Device so wegzuschnappen, daß sudo evtest bzw. sudo ir-keytables -t gar keine Tasten mehr anzeigen (statt dies wenigstens nach sudo service lirc stop zu tun) ?


    Trägt man Geräte in /usr/share/X11/xorg.conf.d/10-evdev.conf explizit zum Ignorieren ein, vermeidet das zwar obige Meldung, aber evtest und ir-keytable zeigen dennoch weiterhin keine Fernbedienungs-Tastendrücke an:

    Code
    1. Section "InputClass"
    2. Identifier "Media Center Ed. eHome Infrared Remote Transceiver"
    3. MatchProduct "Media Center Ed. eHome Infrared Remote Transceiver"
    4. MatchIsKeyboard "true"
    5. Option "Ignore" "true"
    6. EndSection

    Am Anfang der RegEx müsste eine 0 stehen - und wird auch funktionieren, solange (d.h. faktisch praktisch immer) jede Aufnahme weniger als 100 VDR- oder 10000 TS-Segmente hat.


    Siehe auch Übliche VDR-Ordnerstruktur in Kodi-Movies einhängen und mit IMDb-Scraper anreichern & http://forum.kodi.tv/showthread.php?tid=129821&pid=2524380#pid2524380 zur aktuellen Diskussion.

    Nun scheint VDR(admin) selbst ja recht erfolgreich dabei zu sein, im EPG die richtigen IMDb-Links anzuzeigen:
    Lässt sich dessen Logik evtl. zweckentfremden, um http://kodi.wiki/view/NFO_file…fo_files_containing_a_URL zu erzeugen und den Scrapern so dann doch ganz einfach Futter zu bieten? :]
    'If you use the "Movies are in separate folders that match the movie title" scraper setting Kodi will use the first nfo file it finds in the folder (other than the .nfo files described above) and apply it to any valid video file it finds in the same folder.'
    Das würde als Einzeiler dann auf [...] hinauslaufen. [...] nur Titel, aber noch keine IMDb-URLs (Deeplinks zum jeweils naheliegendsten Einzeltitel) erzeugend, da aktuell wohl nur https://www.omdbapi.com/ (o statt i) verfügbar und http://manpages.ubuntu.com/manpages/prec…imdb-get.1.html aus den Distros verschwunden.


    OSMC hat gerade Kodi 17 bekommen, IMDb lässt sich darin wohl nur mit dem (sehr zeitintensiven) "Flagship" http://kodi.wiki/view/Add-on:Universal_Movie_Scraper abernten, das zumindest mit wie o.g. erzeugten NFOs noch nichts anfangen kann: Die Datenbank wird trotz entsprechender Einstellung nicht nach Ordnern zusammengefasst, und enthält unzählige Einträge mit 001 im Namen...
    Versuche auch die KODI-Seite auf VDR zuzubewegen: http://forum.kodi.tv/showthread.php?tid=129821&pid=2524380#pid2524380

    Man fügt die PVR Verzeichnisse über "Browse" hinzu (dort wird das PVR Addin dann auf der ebene anderer Quellen wie z.B. SMB gezeigt.
    Es entsteht ein Link in der Art:
    pvr://recordings/TV (oder ähnlich)


    Diese Daten können dann auch gescraped werden.

    D.h. direkt wie vom VDR kopiert/freigegeben, ohne VNSI und ohne VDRnfoFS?
    Wie bist Du genau vorgegangen?


    Könnte mir auch vorstellen, ein Skript durch alle Unterverzeichnisse pflügen und zu jedem mit 0*.[vdr|ts], d.h.

    Code
    1. dirname $(find /var/lib/video.00 -name '0*.vdr' -or -name '0*.ts') | uniq -u

    den Namen der 2. Verzeichnisebene über dem jeweiligen Film (dessen Segmente ja in 2* liegen) in eine Beschreibungsdatei (soweit noch nicht vorhanden) schreiben zu lassen - wenn ich wüsste, welches Format für Kodi am verdaulichsten ist:
    http://kodi.wiki/view/NFO_file…FO_file_.28recommended.29 und http://kodi.wiki/view/NFO_files/movies#Movie_sets scheinen die Aufsplittung auf mehrere .vdr- bzw. .ts-Dateien nicht zu lösen (und manuelles Verlinken auf IMDb o.ä. pro Film zu erfordern).


    http://kodi.wiki/view/File_sta…e_extensions_for_stacking ("Important: THIS IS THE MOST IMPORTANT STEP TO A SUCCESSFUL LIBRARY SCAN!") verlangt derzeit deutlich von VDR abweichende Konventionen (was sich doch aber bei der hiesigen Programmiererdichte und Größe unserer Archive ändern lassen sollte?).


    Nun scheint VDR(admin) selbst ja recht erfolgreich dabei zu sein, im EPG die richtigen IMDb-Links anzuzeigen:
    Lässt sich dessen Logik evtl. zweckentfremden, um http://kodi.wiki/view/NFO_file…fo_files_containing_a_URL zu erzeugen und den Scrapern so dann doch ganz einfach Futter zu bieten? :]
    'If you use the "Movies are in separate folders that match the movie title" scraper setting Kodi will use the first nfo file it finds in the folder (other than the .nfo files described above) and apply it to any valid video file it finds in the same folder.'
    Das würde als Einzeiler dann auf ein Ungetüm etwa folgenden Kalibers hinauslaufen:

    Quote

    while read -r r; do if [ ! -f $r/$(basename $(dirname $r)).nfo ]; then echo $(basename $(dirname $r)) >$r/$(basename $(dirname $r)).nfo; fi; done < <(dirname $(find /var/lib/video.00 -name '0*.vdr' -or -name '0*.ts') | uniq -u)

    Achtung: Intolerant gegenüber Leerzeichen im Pfadnamen (z.B. Mountpoint/Label externer Platte; wie maskieren wenn \040 nicht geht?) - und nur Titel, aber noch keine IMDb-URLs (Deeplinks zum jeweils naheliegendsten Einzeltitel) erzeugend, da aktuell wohl nur https://www.omdbapi.com/ (o statt i) verfügbar und http://manpages.ubuntu.com/man…cise/man1/imdb-get.1.html aus den Distros verschwunden.
    Man könnte zweistufig erst z.B. http://akas.imdb.com/find?q=Avatar&s=tt evtl. ohne &exact=true, dann RegEx auf <td class="result_text"> <a href="/title/tt0499549/ versuchen; ganz grob immer den 1. Treffer greifend:

    Quote

    while read -r r; do echo http://imdb.com$(wget -O - "$(echo "http://imdb.com/find?s=tt&q="$(basename $(dirname $r) | sed s/_/\ /g | sed s/%//g))" | grep -o "/title/tt[^\/]*/" | head -n 1) >$r/$(basename $(dirname $r)).nfo; done < <(dirname $(find VDR -name '0*.vdr' -or -name '0*.ts') | uniq -u)


    Für Tests (dry run) jeweils den Schreibvorgang scharfschaltendes > lieber erst mal weglassen... :rolleyes:

    Neuer Thread, da [XBMC] Welcher Scraper ist der beste? schon eine Weile her:


    VDR-Aufnahmen liegen ja je nach Alter in folgender Struktur ab (davon inzwischen einige Terabyte):
    /var/lib/video.00/Film/2014-12-17.23.20.35-0.rec/00001.ts 00002.ts index info
    /var/lib/video.00/%Next/2009-12-27.20.12.50.99.rec/001.vdr 002.vdr index.vdr info.vdr marks.vdr resume.vdr


    Wie ist ein einigermaßen aktueller Kodi (z.B. v16 in osmc.tv) dazu zu bewegen, diese richtig in sein eigenes Movies-Menü einzuhängen und aus IMDb zu bebildern und verschlagworten?


    Code
    1. video.0?
    2. %X-Men_Origins#3A_Wolverine
    3. 2*.rec
    4. 001.vdr bzw. 00001.ts usw.


    Kodi (f/k/a XBMC) mag diese Ordnerstruktur von Haus aus offenbar gar nicht und versucht als Filmtitel 001 bis 003 usw. nachzusehen (IMDb-Antworten sind dann ein paar kyrillische und immer wieder eine gewisse Greta), selbst wenn zum Start das VDR-Verzeichnis (entsprechend /var/lib/video.00) eingestellt und die Rekursion in Unterordner abgeschaltet ist.


    Auch legt Kodi jeden Film mehrfach an, wenn er auf weitere MPEG-2-Dateien wie 00002.ts oder 003.vdr trifft (die eigentlich wie z.B. auch von VLC bei Verzeichniswiedergabe nacheinander abgespielt werden sollten), obwohl die Option nicht gesetzt ist, dass der Ordner mehrere Episoden einer Serie enthalte.
    D.h. Kodi kommt auch mit der üblichen Segmentierung in 1-2 GB große Aufnahmedateien nicht klar.


    Wie ist das richtige Vorgehen zur Vermeidung beider Probleme für eine über Jahre gewachsene VDR-Sammlung?
    Kommt Kodi mit einem VDRnfoFS besser klar? (Vgl. nfo Datei für Kodi aus info Datei erzeugen)
    Texte dürfte Kodi ggf. auch aus info(.vdr) übernehmen.


    Lüfterlos im Auftrag des WAF unterwegs, bremst schon die schiere Rechenkraft des Raspberry Pi 2 einige eigene Experimente...

    Bzgl. ps2ts o.ä. für vdrnfofs habe ich bei Tobi mal angefragt, vgl. http://projects.vdr-developer.org/issues/2054 oder ggf. (wenn statt des FUSE der DLNA-Server transkodieren soll) auch durch unterschiedliche Dateiendungen nach Art von http://projects.vdr-developer.org/issues/1521 zu lösen.

    Zur nächsten Weihnacht gab's dann folgendes zu testen: :]
    (Hoffe es ist recht, das mit bestem Dank an eTobi gleich hier zu erwähnen!)

    /etc/fstab wrote:

    # absolute path required for Ubuntu per http://projects.vdr-developer.org/issues/807
    /usr/local/bin/vdrnfofs /mnt/VDR fuse ro,video=/var/lib/video.00,allow_other,noauto,pes=mpg,ts=mpeg 0 0

    Das ermöglicht, TS (.ts) von PES (.vdr) zu unterscheiden, um beide dem Client als mp(e)g zu präsentieren, aber anhand des fehlenden Buchstabens die älteren dem http://mediatomb.cc/pages/transcoding zuzuführen.


    (noauto da FUSE-Automount nicht immer funktioniert, vgl. Enna und vdrnfofs für vdr-ng-experimental/squeeze und DLNA und VDR mit M3U Files).


    Wie nachstehend zu sehen, gestaltete sich die Einbindung unter Ubuntu 14.04 zunächst recht schwierig.
    Schließlich habe ich sie über VLC in etwas ungewöhnlicher Betriebsart gelöst (der Nachlauf zur Vermeidung abschließenden Festhängens bei "main mux warning: no more input streams for this mux" wird wohl je nach Client und Cache noch um einige Sekunden zu verlängern sein, damit der Puffer bis zum Ende des TS vollständig sauber wiedergegeben wird):

    /etc/mediatomb/ps2ts.sh wrote:

    echo "ps2ts.sh" $1 $2 >>/var/log/ps2ts.log
    /usr/bin/cvlc -v --intf dummy $1 --sout 'file/ts:'$2 --stop-time 5 vlc://quit 2>&1 | cat >>/var/log/ps2ts.log
    #/usr/bin/ps2ts $1 $2 2>&1 | cat >>/var/log/ps2ts.log


    .vdr-Dateien mag /usr/bin/ps2ts nicht:


    mencoder (zu mplayer) erzeugt wohl weiterhin keine sauberen mpegts-Ausgaben.


    ffmpeg ist zumindest bei Debian-basierten Distributionen einschränkt/problematisch: http://de.comp.os.unix.linux.m…es-video-format-umwandeln


    Handbrake aus http://www.vdr-portal.de/board…?postid=899256#post899256 und
    ProjectX (headless Java) erscheinen etwas aufwendig, um nur PES in TS umzugießen (und dauerhaft auf einem eher schwach motorisierten NAS o.ä. zu laufen).


    Gelandet bin ich letztlich bei cvlc nach https://www.videolan.org/doc/vlc-user-guide/en/ch04.html und http://www.wondershare.com/vlc…nes-you-need-to-know.html (das o.g. -v zu Diagnosezwecken soll noch anderen Parametern weichen, u.a. um ganz zu vermeiden, daß der Shell-Aufruf für MediaTomb X11 und PulseAudio zu initialisieren versucht) und der DLNA-Serverkonfiguration mit nachfolgend markierten wesentlichen Abweichungen gegenüber (z.T. schlicht falsch/unvollständig ausgelieferten) Ubuntu-LTS-Defaults:

    video/pes ist kein m.W. definierter MIME-Typ, sondern hier als Zwischenstufe eingefügt, um nicht gleich vom Player erkannt, sondern unter Verstecken der Ausgangsdatei durch MediaTomb mit externem Helper nach video/mpeg konvertiert zu werden (da ich keine einfache Unterscheidung anhand FourCC gefunden habe) - sehe mir gerne bessere Vorschläge an.


    (Bzgl. YouTube motzt das Log obwohl gar nicht "enabled".)


    Komplettes Neueinlesen des VDR-Verzeichnisses klappt am ehesten, indem es per MediaTomb-Webinterface http://localhost:49152 (oder höher) aus der "Database" gelöscht und neu einhängt wird über:
    "Filesystem, add as autoscan dir, Inotify, Full, Recursive".


    Nicht nach UTF-8 konvertierte Verzeichnis- und im VDRnfoFS entsprechend Dateinamen (hierfür bei gestopptem VDR sehr nützlich: convmv) brechen auch bei wie oben auf UTF-8 korrigierter config.xml am ersten Sonderzeichen (Umlaut/ß) mit iconv-Fehler in /var/log/mediatomb.log ab, also ggf. vor dem Neueinhängen (zwecks Rescan) und VDR-Wiederanlauf alles umbenennen.


    Kleine Inkonsistenzen in den üblicherweise über Orbit und das bei den Kabelgesellschaften so beliebte 256QAM geschickten Streams bügelt die oben geschilderte Lösung praktischerweise auch gleich so aus, daß sich auch empfindliche Decoder auf BluRay-Qualität ausgerichteter DLNA-Clients nicht daran verschlucken.