Probleme mit Playback von LiveTV (Raspberry PI)

[HElados]

Hallo,

meine Probleme sind folgende:

 1) Manchmal treten waehrend der wiedergabe von livetv sowohl bei hd als auch bei sd blockartefakte auf. Manchmal sind diese gruen, und manchmal haben sie undefinierten inhalt. es liegen immer so 1 bis 2 minuten zwischen den artefakten. In den logfiles finde ich keine auffaelligkeiten, also keine fehler oder warnings die auf irgendwas hinweisen wuerden.

Die CPU auslastung ist bei sd playback so zwischen 60 und 70% und bei hd playback so zwischen 70 und 80%.

Der Befehl

Code: [Auswählen]

/opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0Ergibt bei der wiedergabe nur immer wiederkehrend folgenden output:

Code: [Auswählen]

SIGNAL: [.................................] ( 99%)  BER:      0 FREQ: 602000000  Hz LOCKED: YES SYM: 6900000 MOD: QAM256weswegen ich das kabel oder das signal ausschliessen wuerde.

  2) Der zweite issue ist wahrscheinlich nicht mit dem ersten verwandt, aber ausschliessen kann ich es nicht. Der prozess mediasrv erzeugt normalerweise eine last von 5-20% wahrend der wiedergabe. Aber alle paar minuten sind es ploetzlich kurz ueber 50% und in diesem moment setzt die wiedergabe aus (standbild) ... es dauert dann einige zeit (bis ueber eine minute, in der der mediasrv prozess bereits wieder eine normale last erzeugt) bis die wiedergabe wieder einsetzt, oft begleitet von blockartefakten. Dieser issue gibt sich in den logfiles ebenfalls nicht zu erkennen und tritt auch sowohl bei sd als auch bei hd wiedergabe (anscheinend sogar gleich haeufig) auf.

  3) Vom dritten issue weiss ich nicht ob er mit den anderen beiden verwandt ist. Beim starten der wiedergabe (in meinem fall von xbmc aus) sehe ich zunaechst nur halbwegs intakte standbilder oft schoen angereichert mit blockartefakten bis nach im mittel 10 sekunden die normale wiedergabe (unterbrochen durch die issues 1) und 2)) einsetzt.

Ich verwende den MediaTV Pro III als DVB-C tuner an einem Raspberry PI unter xbian. Den USB transfer mode habe ich auf bulk gestellt. Der stick haengt an einem usb hub mit eigener stromversorgung, und dmesg zeigt keine auffaelligkeiten dass was beim erkennen schief gelaufen waere. Die mediasrv version ist

Code: [Auswählen]

root@xbian:~# /opt/bin/mediasrv --build
Build date: 2014-03-12 15:13:57

Es waere nett wenn sie mir hier helfen koennten ... vielleicht ist es einfach nur eine kleine fehlkonfiguration

Vielen Dank!

HElados

[pbr]

Ich habe auf meinem Pi (moderat übertaktet) mit Raspbian, tvheadend und DVB-C ebenfalls Problem (1). Habe auch immer 99% Signalstärke, habe auch schon ohne Kabel getestet (Stick direkt an der Dose) was keinen Unterschied macht. Einige Sender scheinen recht problemlos zu laufen, andere sind praktisch selten mehr als 5 Sekunden am Stück flüssig.
Der Stream wird auf einem anderen Gerät (per LAN oder WLAN angeschlossen) wiedergegeben.
CPU-Auslastung ist normalerweise ca. 50% (35% tvheadend + 15% sundtek).
Treiber und Raspbian sind aktuell, tvheadend ist die aktuelle, offizielle stable-version (3.4).
Falls es euch was sagt: Ich durfte eben einige "Continuity counter errors" im Log feststellen.

[HElados]

Hallo pbr,

Falls es euch was sagt: Ich durfte eben einige "Continuity counter errors" im Log feststellen.

In welchem log findest du denn die continuity errors?

Wenn ich das nachschaun koennte koennten wir vielleicht herausfinden ob die issues wirklich die selben sind.

HElados

[Sundtek]

Welchen Raspberry PI habt ihr?

Raspberry PI rev B UK?
Raspberry PI rev B China?
Raspberry PI rev A?

[pbr]

Rev B UK, produziert Ende 2013

[Sundtek]

Der Transponderstream von den Sendern die alle paar Sekunden Probleme bereiten wäre interessant.

Im Grunde liegt das Problem wohl eher bei TVHeadend das es zuviel CPU verbraucht (oder verursacht, z.B durch zuviele Filter). Unser Treiber ist an dieser Stelle komplett optimiert.
Eventuell kannst du dich via Skype (sundtek) oder http://chat.sundtek.de mal melden.

[HElados]

Hmm ... als ich habe auch model b ... allerdings weiss ich nicht ob aus uk oder china ... wie kann man das rausfinden?

Und ich hatte vorher einen usb dvb t stick von avermedia, mit dem konnte ich problemlos sd tv schaun ... und auch jetzt ist das problem bei hd und sd gleichermassen aufgetreten, und auch gleich haeufig, und die cpu ist nur dann auf 100%, wenn der mediasrv prozess 50% der cpu belegt ... sonst ist sie immer um 20-30% idle (alle werte laut top) ...

Ich habe auch schon ein script geschrieben dass die prozessorlast von mediasrv, tvheadend und xbmc aufzeichnet ... wenn ich jetzt noch an den fernseher komme (belegt von "1,2 oder 3" -.-)  dann schreibe ich mal ein logfile raus und poste hier nen plot davon ...

Im Moment teste ich es mit der ARD vom Muenchner Kabelnetz ... fuer HD nehme ich auch die ARD ... wie kann ich euch dazu mehr details zum "transponderstream" geben?

Seid ihr auch unter der woche abends (ab 18 oder 19 uhr) erreichbar per skype oder chat? Heute abend gehts bei mir leider nicht ...

HElados

[Sundtek]

Der Stick kann auch DVB-T.

DVB-C und DVB-T haben einen großen unterschied bei der Bandbreite, was sich natürlich auf die CPU Last niederschlägt.

Wenn die USB Anschlüsse nach rechts schauen, steht ganz links oberhalb des CE und FCC Logos Made in the UK.
Es gibt auf vdr-portal.de Meldungen diesbezüglich das nur die UK Versionen funktionieren (das hat sogar ein Kunde herausgefunden, wir haben hier nur Rev A welche solala funktionieren, und Rev B made in UK .. welcher aber noch immer auf der Liste zum Testen steht).

[HElados]

Wenn die USB Anschlüsse nach rechts schauen, steht ganz links oberhalb des CE und FCC Logos Made in the UK.

Ok, da steht gottseidank "Made in the UK"

Ich habe mal die prozessorlast von mediasrv und den beiden anderen hauptverantwortlichen prozessen xbmc und tvheadend geplottet, siehe hier

Jeder der roten spikes von mediasrv stimmt mit entweder einem artefakt oder einem hangup ueberein bei der wiedergabe ... zumindest was ich so beobachten kann ... ich habe keinen weg gefunden die frames per second oder anderes mitzuplotten ...

Und der effekt ist sowohl bei sd als auch bei hd ganz deutlich und rein subjektiv gleich stark sichtbar ... manchmal kann man fast eine halbe minute ohne probleme fluessig fernsehen, dann auf einmal geht es wieder los ...

Die grosse last am anfang stammt vom einschalten der wiedergabe ... hier ist wohl xbmc verantwortlich, spaeter aber wuerde ich es mediasrv ankreiden ...

Kann man irgendwie herausfinden wodurch die hohe last von mediasrv verursacht wird?

Vielleicht laesst sich das ja abstellen ...

Und ja, es gibt hier auch spikes von tvheadend, aber ich kreide es der geringen zeitlichen aufloesung meines plots an, wenn ich es mit top -d 0.3 beobachte, dann gibts zu jedem tvheadend spike immer auch einen mediasrv spike ... wenn ich mal laenger zeit aheb werde ich mal die wiedergabe von dvb-t versuchen ... die hat mit dem avermedia stick ja schonmal funktioniert inkl tvheadend ...

[Sundtek]

Die Last wird sicherlich durch diverse Filtereinstellungen von tvheadend verursacht, Hast du schon einmal HD mit OMXPlayer getestet?

[HElados]

Die Last wird sicherlich durch diverse Filtereinstellungen von tvheadend verursacht, Hast du schon einmal HD mit OMXPlayer getestet?

Hab ich eben versucht mit dem omxplayer von

  http://omxplayer.sconde.net/

mit dem build date 15/03/2014 22:00 UTC, allerdings meldet der sich bei

 

Code: [Auswählen]

omxplayer /dev/dvb/adapter0/dvr0
nur mit einem wenig aussagekraeftigen

 

Code: [Auswählen]

have a nice day ;)
und beendet sich sofort. Der mplayer kann den pfad allerdings abspielen (er ist aber nicht schnell genug), weswegen ich vermute dass ich eine nicht funktionierende omxplayer version habe.

Welche wuerdet ihr denn empfehlen? apt-cache search liefert keine aus dem xbian replository ... und selber von source bauen wuerde ich jetzt nicht versuchen, haette lieber gerne eine "known good version" zum testen

[Sundtek]

Die Verwendung von OMXPlayer ist eigentlich nur um zu testen ob es hilft die Last von tvheadend zu entfernen.

Der Kollege baut hier noch an der neuen Teststrasse rum, denke das sollte bis morgen dann auch soweit sein dann können wir den RPI auch wieder mal in Betrieb nehmen und längerfristig laufen lassen.

[pbr]

Habe im Moment viel zu tun, bin daher noch nicht dazu gekommen mich nochmal zu melden oder der Sache weiter auf den Grund zu gehen. Nachdem ich aber eben gerade wieder große Probleme hatte, hier [1] mal ein Logauszug (tvheadend). In der dem Log entsprechenden Zeit gab es massenhaft Artefakte und einige Aussetzer. Hatte vorher auf einem anderen Sender (siehe [2]), alle paar Minuten sekundenlange Aussetzer. Ein VLC Neustart hat dann wieder 2-5 Minuten Ruhe gebracht, danach wieder das gleiche Spiel.

Log [1]
Mar 23 22:21:01.538 htsp: Got connection from 192.168.2.1
Mar 23 22:21:01.541 htsp: 192.168.2.1: Welcomed client software: VLC media player (HTSPv12)
Mar 23 22:21:01.604 subscription: "192.168.2.1 [ VLC media player ]" subscribing on "6rn HD", weight: 150, adapter: "Sundtek DVB-C (III)", network: "Digital mustcarry", mux: "Digital mustcarry: 618,000 kHz", provider: "", service: "6rn HD", quality: 100
Loglevel debug: enabled
Mar 23 22:21:48.066 TS: Sundtek DVB-C (III)/Digital mustcarry: 618,000 kHz/6rn HD: Transport error indicator
Mar 23 22:21:48.160 TS: Sundtek DVB-C (III)/Digital mustcarry: 618,000 kHz/6rn HD: H264 @ #5000: Continuity counter error
Mar 23 22:21:48.440 TS: Sundtek DVB-C (III)/Digital mustcarry: 618,000 kHz/6rn HD: TELETEXT @ #592: Continuity counter error
Mar 23 22:21:48.616 TS: Sundtek DVB-C (III)/Digital mustcarry: 618,000 kHz/6rn HD: MPEG2AUDIO @ #5001: Continuity counter error
Mar 23 22:21:49.007 TS: Sundtek DVB-C (III)/Digital mustcarry: 618,000 kHz/6rn HD: Transport error indicator, 35 duplicate log lines suppressed
Mar 23 22:21:49.241 TS: Sundtek DVB-C (III)/Digital mustcarry: 618,000 kHz/6rn HD: MPEG2AUDIO @ #5001: Continuity counter error, 1 duplicate log lines suppressed
Mar 23 22:21:49.242 TS: Sundtek DVB-C (III)/Digital mustcarry: 618,000 kHz/6rn HD: H264 @ #5000: Continuity counter error, 5 duplicate log lines suppressed
Mar 23 22:21:50.007 TS: Sundtek DVB-C (III)/Digital mustcarry: 618,000 kHz/6rn HD: Transport error indicator, 46 duplicate log lines suppressed
Mar 23 22:21:50.515 TS: Sundtek DVB-C (III)/Digital mustcarry: 618,000 kHz/6rn HD: H264 @ #5000: Continuity counter error, 6 duplicate log lines suppressed
Mar 23 22:21:51.039 TS: Sundtek DVB-C (III)/Digital mustcarry: 618,000 kHz/6rn HD: Transport error indicator, 55 duplicate log lines suppressed
Mar 23 22:21:52.063 TS: Sundtek DVB-C (III)/Digital mustcarry: 618,000 kHz/6rn HD: Transport error indicator, 58 duplicate log lines suppressed
Mar 23 22:21:53.013 TS: Sundtek DVB-C (III)/Digital mustcarry: 618,000 kHz/6rn HD: Transport error indicator, 61 duplicate log lines suppressed

[ viele identische/ähnliche Zeilen entfernt ]

Mar 23 22:22:26.166 TS: Sundtek DVB-C (III)/Digital mustcarry: 618,000 kHz/6rn HD: H264 @ #5000: Continuity counter error, 71 duplicate log lines suppressed
Mar 23 22:22:27.009 TS: Sundtek DVB-C (III)/Digital mustcarry: 618,000 kHz/6rn HD: Transport error indicator, 471 duplicate log lines suppressed
Mar 23 22:23:57.408 TS: Sundtek DVB-C (III)/Digital mustcarry: 618,000 kHz/6rn HD: Transport error indicator
Mar 23 22:24:48.513 TS: Sundtek DVB-C (III)/Digital mustcarry: 618,000 kHz/6rn HD: Transport error indicator

Log [2]
Mar 23 20:53:34 raspberrypi tvheadend[2058]: mkv: Live stream: Write failed -- Broken pipe
Mar 23 20:53:34 raspberrypi tvheadend[2058]: webui: Stop streaming /stream/channelid/26, muxer reported errors

[Sundtek]

Scheint so als ob TVheadend wohl etwas überlastet ist, eventuell durch das Caching für das Netzwerk.
Wie sieht denn die CPU Last auf deinem Raspberry PI aus?

Streamst du via W-Lan oder Ethernet? (W-Lan kann zusätzlich Last verursachen)

[pbr]

Bei Fall [1] per Ethernet, bei [2] per WLAN. TVheadend braucht etwa 35% CPU, Load ist gleichmäßig etwa bei 0.5 (sowohl 1min, 5min, 15min).