Frage zu Hardware PIDs und dem Netzwerktreiber

[mur]

Hallo,
ich besitze einen MediaTV Pro III Stick von Ende April 2014 .
Ich benutze den Stick primär an einem RaspberryPi Model B (Raspbian, Kernel Version 3.10.25) mit tvheadend zum Streamen, nutze ihn ab und zu aber auch direkt an einem Linux Mint 16 Rechner (x64, Kernel Version 3.11.0-12) mit Kaffeine. Folgendes wurde sowohl auf dem Raspberry als auch auf Linux Mint getestet.
Ich wollte die Hardware PIDs aktivieren um Bandbreite zu sparen, um z.B. auch den Netzwerktreiber auf Windows effektiv nutzen zu können.
Leider kann ich die PIDs nicht aktivieren:

Code: [Auswählen]

$ /opt/bin/mediaclient -P on
Using device: /dev/dvb/adapter0/frontend0
Hardware filter is currently disabled
changing status
done
Egal wie oft ich den Befehl ausführe, die PIDs stehen immer auf deaktiviert – egal ob ein Sender eingestellt ist oder nicht.
In den Logs taucht nach diesem Befehl nur ein kurzes:

Code: [Auswählen]

2014-05-30 00:56:22 [3393] Waking up device
2014-05-30 00:56:22 [3393] mute fm radio
2014-05-30 00:56:22 [3393] Switching to Digital TV
2014-05-30 00:56:23 [3393] Power up demodulator
2014-05-30 00:56:24 [3393] SETTING DVB-C
2014-05-30 00:56:39 [3393] Enabling Standby
auf. Auch während ein Sender aktiv ist, ändert sich nichts daran. Die PID Liste ist auch immer leer:

Code: [Auswählen]

$ /opt/bin/mediaclient -w
Using device: /dev/dvb/adapter0/frontend0
ID   | PID
----------
no pid filters are set
Wenn ein Sender eingeschaltet ist, kann ich in der Liste der Verbundenen Endgeräte beobachten, dass oft nur 5-10 Einträge bei /demux0 eingetragen sind, z.B.:

Code: [Auswählen]

/opt/bin/mediaclient --lc
**** List of Media Clients ****
/dev/dvb/adapter0/frontend0:
  6212 ... kaffeine
/dev/dvb/adapter0/dvr0:
  6212 ... kaffeine
/dev/dvb/adapter0/demux0:
  6212 ... kaffeine (0107)
  6212 ... kaffeine (0012)
  6212 ... kaffeine (023d)
  6212 ... kaffeine (023e)
/dev/video1:
  No client connected
/dev/vbi0:
  No client connected
/dev/radio0:
  No client connected
/dev/rds0:
  No client connected
/dev/mediainput0:
  No client connected
/dev/dsp0:
  No client connected
…., was ja eigentlich die Hardware PIDs nicht ausreizen sollte. Jedoch:

Code: [Auswählen]

/opt/bin/mediaclient -P on
aktiviert immer noch keine Hardware PIDs und mediaclient –w zeigt auch keine an.

In DVBViewer 5.1 in Verbindung mit den Windows 7 x64 Netzwerktreibern kann ich in den Einstellungen auch „ganzen Transponder öffnen“ nicht deaktivieren, da die Checkbox ausgegraut ist. Die genutzte Bandbreite über das Netzwerk ist, wenn ich es richtig sehe, bei rund 4-5 MB/s. Während DVBViewer läuft, zeigt /opt/bin/mediaclient --lc keine Einträge unter demux an.

Wenn ich es richtig verstanden habe, sollte mit den PIDs jedoch nicht der ganze Transponder versendet werden und auch die Bandbreite sinken – oder habe ich da etwas falsch verstanden?
Mache ich irgendwo etwas falsch? Oder ist das hier eher ein Anzeigefehler, da unter demux oft etwas eingetragen ist?

Ich habe alles mit dem Treiber von Ende April und mit dem neuesten Treiber (28.05.) getestet.
Die einzige Änderung (bisher nur auf dem Raspberry getestet): mit dem neuesten Treiber friert der DVBViewer beim Tunen ein -  mit dem alten Treiber reproduzierbar nicht. Wird da unter Umständen eine noch nicht veröffentlichte neue Version des Netzwerktreibers benötigt?
--
Ich bezweifle zwar, dass das folgende damit etwas zu tun hat, in den Logs habe ich jedoch noch gefunden:
Auf dem RaspberryPi taucht während des Fernsehens im 6 Sekunden Takt in den Logs folgendes auf:

Code: [Auswählen]

2014-05-30 00:45:12 [543] CRC invalid of requested section (0014, 637235ec/94522e6/5/small packet)
2014-05-30 00:45:18 [543] CRC invalid of requested section (0014, 637235ec/154522e6/5/small packet)
2014-05-30 00:45:24 [543] CRC invalid of requested section (0014, 637235ec/214522e6/5/small packet)
2014-05-30 00:45:30 [543] CRC invalid of requested section (0014, 637235ec/274522e6/5/small packet)
2014-05-30 00:45:36 [543] CRC invalid of requested section (0014, 637235ec/334522e6/5/small packet)
2014-05-30 00:45:42 [543] CRC invalid of requested section (0014, 637235ec/394522e6/5/small packet)
Auf dem Linux Mint Rechner ist keine solche Meldung in den Logs, jedoch taucht da sporadisch folgender Eintrag auf:

Code: [Auswählen]

[6421] TS Sync byte not aligned, realigning stream (0 // 0)
Beide Einträge tauchen sowohl im Iso als auch im Bulk Modus auf.

Das Signal ist jedoch immer gut:

Code: [Auswählen]

$ /opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0
== reading digital TV signal ==
SIGNAL: [.................................] ( 99%)  BER:      0 FREQ: 114000000  Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [.................................] ( 99%)  BER:      0 FREQ: 114000000  Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [.................................] ( 99%)  BER:      0 FREQ: 114000000  Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [.................................] ( 99%)  BER:      0 FREQ: 114000000  Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [.................................] ( 99%)  BER:      0 FREQ: 114000000  Hz LOCKED: YES SYM: 6900000 MOD: QAM256
SIGNAL: [.................................] ( 99%)  BER:      0 FREQ: 114000000  Hz LOCKED: YES SYM: 6900000 MOD: QAM256
Da ich auch problemlos fernsehen kann, kann ich diese Log-Einträge wahrscheinlich ignorieren, oder?

Danke für die Hilfe!


---------
Etwas komplett unwichtiges:
Wenn ich den Treiber mit aktivierten Logs starte, erscheint in der Konsole

Code: [Auswählen]

2014-05-30 12:06:12 [3332] Alsa Blocking on (default)statt in den Logs. Hier wird wohl einfach der Text falsch umgeleitet?

[xoxol13]

Also mit den PID´s hab ich das gleiche.

Mit der Einstellungen auch ganzen Transponder öffnen im DVBView Verzeichnis gibt es konfig als xml Datei. Das kann man dort abstellen. Aber trozdem nur mit TVheadend läuft es ruckelfrei, DVBView ruckelt wie blöd bei mir.

[Sundtek]

Wir werden das Streaming demnächst noch weiter überprüfen, es gibt einige Performanceoptionen welche wir versuchen werden automatisch zu regeln; aktuell wird jedoch an einem weiteren Treiberupdate an anderer Stelle gearbeitet. Ich denke Anfang kommender Woche sollte sich für das Netzwerk mehr Zeit finden lassen.