[Prototyp] RPI Ausgabeplugin

Moorviper · 12. November 2013

Also für den endgültigen produktiv-einsatz fehlt meiner Meinung nach nicht mehr viel

das 5.1 ton-problem bei diversen hd sendern (siehe oben)
und das das bild ab und kurz schwarz wird

das es nach dem umschalten mal kurz schwarz wird kann man meiner meinung nach verkraften

was sonst noch nice to have wäre: eine Mediaplayer-Unterstützung

mule · 12. November 2013

Zumindest bei mir ist mit der MLD-Version noch keine wirkliche Stabilität gegeben. Entweder er hängt irgendwann oder rebootet.

reufer · 12. November 2013

Zitat von vectra130

Hi Reufer.

Würdest du nochmal einen kurzen Zwischenstand geben wie es aktuell mit der Entwicklung aussieht und worauf wir uns beim nächsten Update freuen können?

Vielen Dank

Also erst die schlechte Nachricht: Ausser Springen in Aufnahmen wird es in der nächsten Version keine "neuen Features" geben. Allerdings, und das ist die gute Nachricht, konnte ich intern einiges umbauen was der Stabilität und Funktionalität sicher zu gute kommt. Leider kann ich momentan nicht so viel daran arbeiten, wie ich gerne möchte, da ich beruflich gerade ziemlich ausgelastet bin. Aber keine Angst, das Projekt ist nicht eingeschlafen!

Gruss
Thomas

P.S. Ich betrachte das Plugin in der aktuellen Version immer noch als Prototypen. Ich bin sehr froh um Feedback von Leuten, die das Plugin unter andern Bedingungen testen können als es mir möglich ist - aber einen Produktiveinsatz würde ich noch nicht empfehlen.

vectra130 · 12. November 2013

Zitat

Aber keine Angst, das Projekt ist nicht eingeschlafen!

Na, was anderes wollte ich doch garnicht hören
Sehr schön. Zu den Feedbacks:
Also ich kann aktuell nicht viel neues berichten. Auf meinen zwei RPi's läuft das die meiste Zeit sehr stabil. Einer läuft mit VDR 2.0.3 und einer mit 2.0.4. Beide werden über Streamdev versorgt.
Zwischenzeitlich hab ich mal kurze Ton und Bild ruckler. Aber wirklich nur selten. Komisch sind halt die komischen MP3 Meldungen auf der Konsole von denen ich einige Beiträge früher von berichtet hatte. Mal sehen ob die nach dem nächsten Update weg sind.

Gerade ist mir was aufgefallen: gucke gerade "The Big Bang Theory". Bei dem Vorspann der aus sehr schnellen Bildwechseln besteht musste ich gerade komplett auf den Ton verzichten. Dauerte nach dem Abspann auch gut 30 Sekunden bis der Ton wieder stotterfrei war. Ist wohl ein Buffer voll gelaufen. Wollte gerade im Log nachsehen, aber syslog hat sich wohl abgeschossen. Schade.

Moorviper · 12. November 2013

Also ich hab mich relativ an die anleitung von swen4 gehalten (bis auf das ich den vdr als root starte)
und keine tonaussetzer

Welche Pi Version hast du denn???
uk oder chinaböller

das macht auch einiges aus

vectra130 · 13. November 2013

Nene, kein Chinaböller

Wie gesagt, die Aussetzer sind sehr selten. Das gestern Abend, das der komplette Vorspann weg ist, ist mir jetzt zum ersten mal aufgefallen. Bin mir auch nicht ganz sicher ob es nicht am WLAN Stick liegt. Zwischendurch sind die Ping Zeiten mal ganz Mies.

reufer · 13. November 2013

Zitat von vectra130

Zwischenzeitlich hab ich mal kurze Ton und Bild ruckler. Aber wirklich nur selten. Komisch sind halt die komischen MP3 Meldungen auf der Konsole von denen ich einige Beiträge früher von berichtet hatte. Mal sehen ob die nach dem nächsten Update weg sind.

Diese Meldungen habe ich, wie gesagt, noch nie gesehen und kann das deshalb leider nicht nachvollziehen.

Das Stottern sollte in der nächsten Version hoffentlich auch weg sein, ich habe die Audio-Decordierung in einen eigenen Thread ausgelagert, was bei mir vor allem beim Replay Mikroruckler im Bild verursachte.

Gruss
Thomas

schlurftock · 13. November 2013

Ich werde mal ein paar probeaufnahmen von den kritischen Sendern machen / die mp3 meldungen kommen bei mir bei ard-hd orf-hd und co
ABER bei mir kommt der Ton und der ist fehlerfrei
Ich denke mal bei vectra 130 liegt es am wlan

vectra130 · 13. November 2013

Ja. Ich glaub langsam auch immer mehr das es am WlAN liegt. Muss wohl doch mal ein Freiluftkabel durchs Haus ziehen
Ich hab die Meldungen jedenfalls auf jedem Sender.

Mal ne andere Frage: ist es eigentlich egal an welcher Stelle man das Plugin aufruft? Oder muss es zB vor/nach Streamdev gestartet werden?
Gibt's da Erfahrungen? Ich hab es einfach mal als erstes und als letztes starten lassen. Das einzige was mir auf die schnelle aufgefallen ist, ist das beim start an erster Stelle das OSD sehr spät angezeigt wird.

Moorviper · 13. November 2013

welchen skin benutzt du ???

vectra130 · 14. November 2013

Aktuell nutze ich den Skinflat. Mit Skinflatplus hab ich das selbe Ergebnis.

Mir fällt gerade noch was ein. Habe auch gelegentlich nach dem Booten des RPi und dem Start des VDR das Problem das das OSD zwar erscheint, aber nicht mehr verschwindet. Ein Fernsehbild hab ich dann auch nicht, es bleibt schwarz und stumm. Es hilft dann nur ein "kill vdr" und danach ist alles gut. Tritt wie gesagt nur manchmal nach dem booten auf. Im Log ist auch nichts ungewöhnliches zu sehen.

Falls es hilft, meinen VDR starte ich folgendermaßen:

Code

VDR_CHARSET_OVERRIDE=ISO-8859-9 LANG=de_DE LC_ALL=de_DE /usr/bin/vdr \
-v /video00/video.00 \
-c /var/lib/vdr \
-L /usr/lib/vdr/plugins \
-r /usr/lib/vdr/vdr-recordingaction \
-s '/etc/vectra130/scripts/suspend.sh Standby' \
-E /var/cache/vdr/epg.data \
-u root -g /tmp --port $SVDRP_PORT --vfat -w 30 -l $VDRLOG \
--lirc \
-P 'rpihddevice' \
-P 'svdrpservice' \
-P 'streamdev-client' \
-P 'tvguide -l /etc/vectra130/images/channellogos/logos/ -i /nfs/vdrserver/epgimages/' \
-P 'osdteletext'  \
-P 'skinflatplus --logopath=/etc/vectra130/images/channellogos/logos' \
-P 'skinflat --logopath=/etc/vectra130/images/channellogos/logos' \
-P 'clock' \
-P 'menuorg' \
-P 'remoteosd' \
-P 'remotetimers' \
-P 'epgsearch' \
-P 'epgsync' \
-P 'admin'

Alles anzeigen

Moorviper · 14. November 2013

hm da lädt das ding aber schon einiges am start

vectra130 · 15. November 2013

Brauch ich aber alles

ollo · 15. November 2013

... die gelegentlichen Aufhänger beim Start habe ich auch und ich lade nur das streamdev & rpihddevice plugin. Außerdem bleibt manchmal die Ausgabe einfach stehen, kann aber per erneuter Kanalwahl reanimiert werden. Ob das nun aber am streamdev oder rpihddevice liegt, muss ich noch prüfen.

Gruß, ollo

Edit: Das Stehenbleiben liegt am streamdev-client. Dort läuft ein socket über und dann wird die Verbindung beendet. Wahrscheinlicht hilft hier den StreamFilter im Client abzuschalten:

Code

Nov 15 20:11:02 raspberrypi vdr: [2989] cStreamdevFilter::PutSection socket overflow, Pid   18 Tid  64
Nov 15 20:11:02 raspberrypi vdr: [2989] cStreamdevFilter::PutSection socket overflow, Pid   18 Tid  64
Nov 15 20:11:02 raspberrypi vdr: [2989] cStreamdevFilter::PutSection socket overflow, Pid   18 Tid  64
Nov 15 20:11:02 raspberrypi vdr: [2989] cStreamdevFilter::PutSection socket overflow, Pid   18 Tid  64
Nov 15 20:11:18 raspberrypi vdr: [2972] ERROR: streamdev-client: Failed reading reply to 'ADDF 2400 2 255' from 192.168.178.32:2004: Die Wartezeit fÃ¼r die Verbindung ist abgelaufen
Nov 15 20:11:18 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (0)
Nov 15 20:11:18 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (1)
Nov 15 20:11:18 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (2)
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (3)
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (4)
Nov 15 20:11:19 raspberrypi vdr: [2989] streamdev-client: Connected to server 192.168.178.32:2004 using protocol version 1.0
Nov 15 20:11:19 raspberrypi vdr: [2989] streamdev-client: Command 'DELF 2100 2 255' rejected by 192.168.178.32:2004: 560 Can't delete filters without a stream
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (5)
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (6)
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (7)
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (8)
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (9)
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (10)
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamdevDevice::GetTSPacket(): disconnected
Nov 15 20:11:20 raspberrypi vdr: [2989] cStreamdevFilters::Action(): stream disconnected ?
Nov 15 20:11:20 raspberrypi vdr: [2989] StreamdevFilters::Action() ended
Nov 15 20:11:20 raspberrypi vdr: [2989] streamdev-client: sections assembler thread ended (pid=2960, tid=2989)
Nov 15 20:11:48 raspberrypi vdr: [2960] streamdev-client: Command 'DELP 2901' rejected by 192.168.178.32:2004: 560 Pid 2901 not transferring
Nov 15 20:11:48 raspberrypi vdr: [2960] streamdev-client: Command 'DELP 2902' rejected by 192.168.178.32:2004: 560 Pid 2902 not transferring
Nov 15 20:11:48 raspberrypi vdr: [2960] streamdev-client: Command 'DELP 2903' rejected by 192.168.178.32:2004: 560 Pid 2903 not transferring
Nov 15 20:11:48 raspberrypi vdr: [3061] streamdev-client: sections assembler thread started (pid=2960, tid=3061, prio=high)
Nov 15 20:14:12 raspberrypi vdr: [3061] cStreamdevFilter::PutSection socket overflow, Pid   18 Tid  64
Nov 15 20:14:12 raspberrypi vdr: [3061] cStreamdevFilter::PutSection socket overflow, Pid   18 Tid  64

Alles anzeigen

Edit2: StreamFilter im Client abzuschalten hilft, jedoch meckert jetzt das rpihddevice im syslog:

Code

Nov 15 21:15:07 raspberrypi vdr: [2976] rpihddevice: Clear()
Nov 15 21:15:07 raspberrypi vdr: [2976] ERROR: TS packet not accepted in Transfer Mode
Nov 15 21:15:29 raspberrypi vdr: [2976] rpihddevice: Clear()
Nov 15 21:15:29 raspberrypi vdr: [2976] ERROR: TS packet not accepted in Transfer Mode
Nov 15 21:15:33 raspberrypi vdr: [2976] rpihddevice: Clear()
Nov 15 21:15:33 raspberrypi vdr: [2976] ERROR: TS packet not accepted in Transfer Mode
Nov 15 21:15:34 raspberrypi vdr: [2976] rpihddevice: Clear()
Nov 15 21:15:34 raspberrypi vdr: [2976] ERROR: TS packet not accepted in Transfer Mode
Nov 15 21:15:37 raspberrypi vdr: [2976] rpihddevice: Clear()
Nov 15 21:15:38 raspberrypi vdr: [2976] ERROR: TS packet not accepted in Transfer Mode
Nov 15 21:15:38 raspberrypi vdr: [2976] rpihddevice: Clear()
Nov 15 21:15:38 raspberrypi vdr: [2976] ERROR: TS packet not accepted in Transfer Mode
Nov 15 21:15:43 raspberrypi vdr: [2976] rpihddevice: Clear()
Nov 15 21:15:43 raspberrypi vdr: [2976] ERROR: TS packet not accepted in Transfer Mode

Alles anzeigen

Torsten73 · 15. November 2013

Zitat von vectra130

Ja. Ich glaub langsam auch immer mehr das es am WlAN liegt. Muss wohl doch mal ein Freiluftkabel durchs Haus ziehen
Ich hab die Meldungen jedenfalls auf jedem Sender.

Für solche Fälle kann man noch auf Powerline Adapter zurückgreifen. Sofern es nicht über verschiedene Stromzähler geht und es kein 1000qm Palast ist. Möglichst noch die gleiche Phase nehmen und der Netzwerkstream ist stabil. Auch bei WLAN mit gutem Empfang aber fehlender Priorisierung kann es Probleme geben.

vectra130 · 15. November 2013

Zitat von ollo

... die gelegentlichen Aufhänger beim Start habe ich auch und ich lade nur das streamdev & rpihddevice plugin. Außerdem bleibt manchmal die Ausgabe einfach stehen, kann aber per erneuter Kanalwahl reanimiert werden. Ob das nun aber am streamdev oder rpihddevice liegt, muss ich noch prüfen.

Gruß, ollo

Edit: Das Stehenbleiben liegt am streamdev-client. Dort läuft ein socket über und dann wird die Verbindung beendet. Wahrscheinlicht hilft hier den StreamFilter im Client abzuschalten:

Code

Nov 15 20:11:02 raspberrypi vdr: [2989] cStreamdevFilter::PutSection socket overflow, Pid   18 Tid  64
Nov 15 20:11:02 raspberrypi vdr: [2989] cStreamdevFilter::PutSection socket overflow, Pid   18 Tid  64
Nov 15 20:11:02 raspberrypi vdr: [2989] cStreamdevFilter::PutSection socket overflow, Pid   18 Tid  64
Nov 15 20:11:02 raspberrypi vdr: [2989] cStreamdevFilter::PutSection socket overflow, Pid   18 Tid  64
Nov 15 20:11:18 raspberrypi vdr: [2972] ERROR: streamdev-client: Failed reading reply to 'ADDF 2400 2 255' from 192.168.178.32:2004: Die Wartezeit fÃ¼r die Verbindung ist abgelaufen
Nov 15 20:11:18 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (0)
Nov 15 20:11:18 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (1)
Nov 15 20:11:18 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (2)
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (3)
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (4)
Nov 15 20:11:19 raspberrypi vdr: [2989] streamdev-client: Connected to server 192.168.178.32:2004 using protocol version 1.0
Nov 15 20:11:19 raspberrypi vdr: [2989] streamdev-client: Command 'DELF 2100 2 255' rejected by 192.168.178.32:2004: 560 Can't delete filters without a stream
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (5)
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (6)
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (7)
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (8)
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (9)
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamDevice::GetTSPacket: GetChecked: NOTHING (10)
Nov 15 20:11:19 raspberrypi vdr: [2990] cStreamdevDevice::GetTSPacket(): disconnected
Nov 15 20:11:20 raspberrypi vdr: [2989] cStreamdevFilters::Action(): stream disconnected ?
Nov 15 20:11:20 raspberrypi vdr: [2989] StreamdevFilters::Action() ended
Nov 15 20:11:20 raspberrypi vdr: [2989] streamdev-client: sections assembler thread ended (pid=2960, tid=2989)
Nov 15 20:11:48 raspberrypi vdr: [2960] streamdev-client: Command 'DELP 2901' rejected by 192.168.178.32:2004: 560 Pid 2901 not transferring
Nov 15 20:11:48 raspberrypi vdr: [2960] streamdev-client: Command 'DELP 2902' rejected by 192.168.178.32:2004: 560 Pid 2902 not transferring
Nov 15 20:11:48 raspberrypi vdr: [2960] streamdev-client: Command 'DELP 2903' rejected by 192.168.178.32:2004: 560 Pid 2903 not transferring
Nov 15 20:11:48 raspberrypi vdr: [3061] streamdev-client: sections assembler thread started (pid=2960, tid=3061, prio=high)
Nov 15 20:14:12 raspberrypi vdr: [3061] cStreamdevFilter::PutSection socket overflow, Pid   18 Tid  64
Nov 15 20:14:12 raspberrypi vdr: [3061] cStreamdevFilter::PutSection socket overflow, Pid   18 Tid  64

Alles anzeigen

Edit2: StreamFilter im Client abzuschalten hilft, jedoch meckert jetzt das rpihddevice im syslog:

Code

Nov 15 21:15:07 raspberrypi vdr: [2976] rpihddevice: Clear()
Nov 15 21:15:07 raspberrypi vdr: [2976] ERROR: TS packet not accepted in Transfer Mode
Nov 15 21:15:29 raspberrypi vdr: [2976] rpihddevice: Clear()
Nov 15 21:15:29 raspberrypi vdr: [2976] ERROR: TS packet not accepted in Transfer Mode
Nov 15 21:15:33 raspberrypi vdr: [2976] rpihddevice: Clear()
Nov 15 21:15:33 raspberrypi vdr: [2976] ERROR: TS packet not accepted in Transfer Mode
Nov 15 21:15:34 raspberrypi vdr: [2976] rpihddevice: Clear()
Nov 15 21:15:34 raspberrypi vdr: [2976] ERROR: TS packet not accepted in Transfer Mode
Nov 15 21:15:37 raspberrypi vdr: [2976] rpihddevice: Clear()
Nov 15 21:15:38 raspberrypi vdr: [2976] ERROR: TS packet not accepted in Transfer Mode
Nov 15 21:15:38 raspberrypi vdr: [2976] rpihddevice: Clear()
Nov 15 21:15:38 raspberrypi vdr: [2976] ERROR: TS packet not accepted in Transfer Mode
Nov 15 21:15:43 raspberrypi vdr: [2976] rpihddevice: Clear()
Nov 15 21:15:43 raspberrypi vdr: [2976] ERROR: TS packet not accepted in Transfer Mode

Alles anzeigen

Wenn ich die Filterdaten im StreamdevClient abschalte hab ich aber nach ein paar Tagen kein EPG mehr. Gibts da ne Alternative? EPGsync funktioniert irgendwie nicht.Solange ich da keine Lösung habe müssen die Filterdaten an bleiben.

reufer · 17. November 2013

Hallo zusammen

Nach längerer Pause konnte ich den Umbau im Audio-Bereich abschliessen und habe nun eine neue Testversion für euch:

Code

2013-11-17: Version 0.0.5
-------------------------
- new:
  - improved audio format detection (taken from softhddevice)
  - separate thread for audio decoding
- fixed:
  - jump forward/backward in recordings
  - several minor bugfixes
- missing:
  - still picture
  - trick modes
  - deinterlacer
  - video format/output options

Alles anzeigen

Wiedergabe funktioniert bei mir nun absolut ruckelfrei, ohne Übertaktung. Ich teste mit ffmpeg 1.0.7 und DVB-S (ausser SRG nur FTA).

Ich möchte nochmal auf den Prototyp-Status hinweisen, bin aber sehr froh um Rückmeldungen von mutigen Testern!

Edit: Wen's interessiert, hier die Plugins die ich benutze und deren (eigentlich zufällige) Reihenfolge:

Code

streamdev-client
remote
rpihddevice
skinenigmang
nordlichtsepg
extrecmenu
menuorg

Grüsse aus Bern
Thomas

reufer · 17. November 2013

Zitat von vectra130

Wenn ich die Filterdaten im StreamdevClient abschalte hab ich aber nach ein paar Tagen kein EPG mehr

Die "socket overflow"-Meldungen habe ich auch im Log, aktuell stören die aber nicht weiter. Ob es da eine Lösung gibt, bzw. was das Problem ist, weiss ich auch nicht...

Gruss
Thomas

reufer · 18. November 2013

Ach ja, noch eine Frage an die verehrte Entwicklerschaft:

Um Audio-only zu erkennen, prüfe ich, ob die Wiedergabe mit einem Audio-Paket beginnt. Bei Live-TV klappt das ohne Probleme, aber bei Aufnahmen habe ich hin und wieder den Fall, dass kein Bild kommt und das Plugin im Audio-only-Mode ist. Habe ich hier noch einen Fehler eingebaut, oder kann es bei der Wiedergabe tatsächlich vorkommen, dass diese - zufällig - mit einem Audio-Paket beginnt?

Wäre der Test auf zwei aufeinander folgende Audio-Pakete besser?

Und, auch in diesem Zusammenhang, woran erkenne ich Video-only? Das wird im Moment nämlich nicht funktionieren, da in dem Fall das Plugin auf ein Audio-Paket zur Synchronisierung wartet. Allerdings wüsste ich jetzt auch nicht, wo ein tonloser Videostream am VDR Sinn macht...

Gruss
Thomas

MartenR · 18. November 2013

Video only könnte bei Tafeln vorkommen auf denen steht das im Moment nicht gesendet wird sondern erst wieder an ....

Marten

[Prototyp] RPI Ausgabeplugin

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema