[yaVDR 0.5] Gelöst: streamdev: Kanäle werden sporadisch nicht hell

löwe · December 27, 2012 at 12:56 AM

Hallo!

Bei meinem yaVDR 0.5 Setup mit Streamdev-Server und -Client kommt es sehr sporadisch vor, dass ein Kanal am Client nach dem Umschalten nicht hell wird.

Das Problem tritt geschätzt alle 50 Umschaltvorgänge auf und kann durch erneutes Hinschalten zum gewünschten Kanal behoben werden. Betroffen sind Sender aller Art (SD, HD, verscchlüsselter ORF).

Log Server:

Code

Dec 27 00:50:24 microserver vdr: [3569] receiver on device 1 thread started (pid=26924, tid=3569)
Dec 27 00:50:24 microserver vdr: [3570] TS buffer on device 1 thread started (pid=26924, tid=3570)
Dec 27 00:50:24 microserver vdr: [26940] Streamdev: Setting data connection to 192.168.1.119:38371
Dec 27 00:50:24 microserver vdr: [3571] streamdev-writer thread started (pid=26924, tid=3571)
Dec 27 00:50:24 microserver vdr: [3572] streamdev-livestreaming thread started (pid=26924, tid=3572)
Dec 27 00:52:10 microserver vdr: [26924] cleaning up schedules data
Dec 27 00:52:21 microserver vdr: [2940] ecmhandler 0/0 filter thread ended (pid=26924, tid=2940)

Log Client:

Code

Dec 27 00:50:22 htpc-eg vdr: [5260] Text2Skin: menu display update thread started (pid=4662, tid=5260)
Dec 27 00:50:23 htpc-eg vdr: [5260] Text2Skin: menu display update thread ended (pid=4662, tid=5260)
Dec 27 00:50:24 htpc-eg vdr: [5261] Text2Skin: channelInfo display update thread started (pid=4662, tid=5261)
Dec 27 00:50:25 htpc-eg vdr: [4662] switching to channel 6
Dec 27 00:50:25 htpc-eg vdr: [4662] [softhddev]SetPlayMode: 0
Dec 27 00:50:25 htpc-eg vdr: [4662] [softhddev]SetVideoDisplayFormat: 1
Dec 27 00:50:25 htpc-eg vdr: [5254] osdteletext-receiver thread ended (pid=4662, tid=5254)
Dec 27 00:50:25 htpc-eg vdr: [4662] buffer stats: 0 (0%) used
Dec 27 00:50:25 htpc-eg vdr: [5255] TS buffer on device 11 thread ended (pid=4662, tid=5255)
Dec 27 00:50:25 htpc-eg vdr: [5253] buffer stats: 439732 (20%) used
Dec 27 00:50:25 htpc-eg vdr: [5253] receiver on device 11 thread ended (pid=4662, tid=5253)
Dec 27 00:50:25 htpc-eg vdr: [5262] receiver on device 11 thread started (pid=4662, tid=5262)
Dec 27 00:50:25 htpc-eg vdr: [5263] osdteletext-receiver thread started (pid=4662, tid=5263)
Dec 27 00:50:25 htpc-eg vdr: [5264] TS buffer on device 11 thread started (pid=4662, tid=5264)
Dec 27 00:50:25 htpc-eg vdr: [4662] [softhddev]SetPlayMode: 1
Dec 27 00:50:25 htpc-eg vdr: video: decoder buffer empty, duping frame (4105/868) 0 v-buf
Dec 27 00:50:25 htpc-eg vdr: video: --:--:--.---   +0    0   0/\ms   0+5 v-buf
Dec 27 00:50:30 htpc-eg vdr: [5261] Text2Skin: channelInfo display update thread ended (pid=4662, tid=5261)
Dec 27 00:50:31 htpc-eg vdr: [5265] Text2Skin: channelInfo display update thread started (pid=4662, tid=5265)
Dec 27 00:50:36 htpc-eg vdr: [5265] Text2Skin: channelInfo display update thread ended (pid=4662, tid=5265)
Dec 27 00:51:07 htpc-eg vdr: video: decoder buffer empty, duping frame (4205/868) 0 v-buf
Dec 27 00:51:07 htpc-eg vdr: video: --:--:--.---   +0    0   0/\ms   0+-1 v-buf
Dec 27 00:52:07 htpc-eg vdr: video: --:--:--.---   +0    0   0/\ms   0+-1 v-buf
Dec 27 00:53:07 htpc-eg vdr: video: --:--:--.---   +0    0   0/\ms   0+-1 v-buf
Dec 27 00:54:00 htpc-eg vdr: [4739] EPGSearch: timer conflict check started
Dec 27 00:54:00 htpc-eg vdr: [4739] EPGSearch: timer conflict check finished
Dec 27 00:54:07 htpc-eg vdr: video: --:--:--.---   +0    0   0/\ms   0+-1 v-buf
Dec 27 00:54:38 htpc-eg vdr: [4662] cleaning up schedules data
Dec 27 00:55:07 htpc-eg vdr: video: --:--:--.---   +0    0   0/\ms   0+-1 v-buf

Display More

Für mich ist besonders seltsam, dass in so einer Situation lt. beiden Logs der Kanal sehr wohl korrekt wiedergegeben wird - das Bild ist aber von Anfang an permantent schwarz.

Woran könnte das Problem liegen?

skippy · December 27, 2012 at 7:27 AM

Hallo Löwe,

ich kenne nur das Umschaltproblem im Streamdev-Plugin, wenn beide Kanäle (aktueller und der, zu dem du umschaltest) auf demselben Transponder liegen. Schau doch mal, ob das bei dir auch der Fall ist. Wenn ja, findest du Abhilfe in der Readme zum Plugin:

Code

* Viewing encrypted channels became an issue with VDR's new CAM handling code.
Streamdev doesn't provide a (dummy) CAM, so out of the box, VDR won't ever try
to receive encrypted channels from streamdev. Pick one of the following
solutions to work around the problem:


1. Force VDR to use streamdev. Open the channels menu on the client (or edit its
channels.conf if you know how to do this) and set the CA field of all channels
that only the server can decrypt to streamdev's device index. Usually streamdev
will get number 9 or 10. Streamdev logs the actual device number when starting
up. So please consider the logs for the correct value. Remember to fill in
hexadecimal values if you are using an editor to modify your channels.conf
(number 10 becomes an "a", number 11 a "b", ...).


2. Apply either patch "patches/vdr-1.6.0-intcamdevices.patch" or patch
"patches/vdr-1.6.0-ignore_missing_cam.diff" to your client VDR. Intcamdevices
is the clean solution, but it modifies the VDR API. So you will need to
recompile all of your plugins. The ignore_missing_cam patch is trivial, no need
to recompile other plugins. However it is not suitable for clients with a DVB
card of their own.

Display More

Viele Grüße skippy

löwe · December 27, 2012 at 11:50 AM

Hallo skippy, Danke für die interessante Antwort!

Ich denke aber, dass davon mein Problem leider nicht (ausschließlich) verursacht wird, denn bei mir tritt der Problemfall auch bei unverschlüsselten Sendern auf (sogar häufiger als beim verschlüsselten ORF, denn FTA-Sender habe ich weit mehr in der Senderliste). Der ORF hingegen wird am Server entschlüsselt, denn dort ist ja schließlich auch ein CAM vorhanden.

Gestern Abend konnte ich dann noch feststellen, dass sich die Umschaltaussetzer nur dann bemerkbar machen, wenn der TV-Tuner im Server (DVBSky S952) gleichzeitig auch noch ein anderes Programm streamt.

Beispiel:

Client 1 streamt den Sender Deluxe Music
Client 2 streamt den Sender ProSieben

Kann das etwas mit den Treibern zu tun haben?

löwe · December 29, 2012 at 1:24 PM

Auch hier konnte ich inzwischen selbst eine Lösung finden: Das Problem war eine zu große channels.conf am VDR-Server.

Dazu ein paar Sätze zu meiner ursprünglichen (die Probleme hervorrufenden) Konfiguration:

Der Einfachheit halber habe ich am VDR-Server eine komplette und vollständige channels.conf verwendet (Donwload aus Channelpedia).
Aus dieser so dann am Server vorhandenen Datei habe ich dann einen kleinen Auszug bestehend aus den benötigten Sendern auf die Clients hin übernommen.

Leider führte genau das zu meinen Problemen:
Besonders dann, wenn beide Clients zugleich aktiv waren, konnte manchmal nicht zu neuen Transpondern gewechselt werden --> das Bild blieb einfach schwarz, ohne Fehlermeldungen in den VDR-Logs (nach deren Infos sehr wohl ein Bild wiedergegeben wird). Trat das Problem auf, wurden keine Kanäle innerhalb des selben Transponders wiedergegeben, auf den soeben gewechselt wurde. Als Abhilfe musste auf einen Kanal eines anderen Transponders gewechselt werden. In einem nächsten Schritt konnte dann aber sofort wieder auf den vorherigen Transponder zurück gewechselt werden, wo der gewählte Kanal dann in der Regel auch sofort wiedergegeben wurde.

War nur ein Client aktiv, funktionierte das Wechseln von Kanälen seltsamerweise problemlos.

Inzwischen habe ich in der channels.conf der VDR-Servers nur mehr jene Kanäle gelistet, die auf den Clients auch tatsächlich verwendet werden - die hunderten nicht verwendeten Kanäle habe ich entfernt.

Damit funktioniert das Wechseln zwischen den Kanälen nun (vorerst) problemlos

[yaVDR 0.5] Gelöst: streamdev: Kanäle werden sporadisch nicht hell

Participate now!

Users Viewing This Thread