[gelöst] mcli ERROR: video data stream broken

HelmutB Beim Diff zwischen

syslog_nurNCVbootSIXX_orf1hd_0211a_nuc_2tun_OK.txt

syslog_nurNCVbootSIXX_orf1hd_0211g_nuc_2tun_NOK.txt

fällt jedenfalls auf dass _NOK ein

Feb 11 11:35:58 BM2LTSNuc64native-MCLI vdr: [1553] retuning due to modification of channel 1 (ORF1 HD)

hat.

Ich werd gleich mal mit der CAID 1 testen ... die FRage ist ob da nicht UpdateChannels gelich drüber bügelt ... im Zweifelsfall deaktiviere ich es mal.

Unten angef. Dateiein hochgeladen:

_0211h und _0211i: Bei UpdateChannels=0 war es mit und ohne :1, OK.

_0211j: Bei UpdateChannels3 auch bei zuvor editierter channels.conf NOK.

ORF2O HD;ORF:11273:HC23M5O35S1:S19.2E:22000:3000=27:0;3001=deu@106,3002=mis@106:3005:1,D98,650,D95,648,6E2,98C,9C4,98D,500:13304:1:1005:0

a) Bei den Tests am Vormittag (s.o.) war es für die Reels auch mit Prio=0 OK ...

Statt "unterer Schacht"(=S11) nun mit "verschlüsselt: _0211e_reelAVG_3tun_verschlüsselt_prio0_OK und _0211f_reelAVG_3tun_verschlüsselt_prio0_OK

b) Edit: ":1," steht auch nach Neustart noch wie oben drin

c) Edit: mit CAID=1 kommt jedenfalls " No CAM can decrypt this program" nicht mehr.

Ev. sind es mehrere Probs, weil ja umgekehrt auch wenn " No CAM can decrypt this program" drin war, das Bild weiter lief.

_0211h und _0211i: Bei UpdateChannels=0 war es mit und ohne :1, OK.

d) Wir haben ja auch nur bei Aufnahmen den "Data stream broken" ... was ist denn im syslog das Indiz dass es nach 30s schief gehen wird ?

!Ich habe bei allen NOK ca. 15-30s nach dem Hänger immer erneut den Kanal angewählt und es war jedes Mal OK ... ev. für Vergleichswert hilfreich!

e) der vdr hat jedenfalls orf2 aktualisiert, aber CAID 1 ist die nach 3005 oder ?

ORF2O HD;ORF:11273:HC23M5O35S1:S19.2E:22000:3000=27:0;3001=deu@106,3002=mis@106:3005:1:13304:1:1005:0

Das passiert bei reelvdr mit Eintrag S11 (unt. Schacht) nicht. Stellt man auf verschlüsselt schon (aber auch da lief das Bild...)

f) Fakt ist mit channelUpdate=0 scheint es zu laufen. Es muss also mit dem WEchsel der devices zusammen hängen oder ?

g) In den Reel syslogs sieht man, dass min. 2(bei S11) - 3x(bei"vrschlüsselt") vom vdr auf 2 geschalten wird (speziell nach den 20-30s)

h) in manchen syslogs fehlt die "Mcli::CAMAvailable:". Ist aber auch nicht konsistent.

Auch mit CAID11 ... mal geht es mal geht es nicht ... falls ich davon log produzieren soll ... gerne. Ich vermute je nachdem wie das UpdateChannels drein funkt geht es hin u wieder. Wenn ich nicht nur den NCV sondern auch den NUC neu starte hängt es jedenfalls auch.

Hochgeladen _0211m OK, _0211n NOK,

Die waren mit CA1 .. genauso verhielt es sich mit CA11

Edit:

Noch eine _0211q mit CA11 wo NUC&NCV booten, Hänger nach ca. 30s, aber irgendwann lief es dann doch weiter. Denke es war nach 1-2min (hatte gar nicht mehr hin gesehen)

Hi HelmutB ich hab mich mal auf die syslogs konzentriert.

Ich hatte nur ein Beisp. wo auch bei Upd.Ch=0 ein _NOK resultierte: _0210d_nuc_UpdChan0_6tun_NOK

Bei den _NOK passiert nach dem manuellen (KEY) "switching" entweder innerhalb weniger Sek. das 2. autom. "switching" vom vdr/mcli oder kein 2.

Bei den _OK reicht oft das 2. autom. switching (z.B. bei UpdChan0, _upd0) nach 4-10s oder er macht auch noch ein weiteres nach den 30s (das brauchen z.B. die reels bei Einstellung "verschlüsselt" im ncv log Priority 0):

_0211e_reelAVG_3tun_verschlüsselt_prio0_OK.txt

_0211f_reelAVG_3tun_verschlüsselt_prio0_OK.txt

Zum ncv:

CA1/11 löst jedenfalls Priority 1 für CAM0 beim NCV aus. Beim überfliegen der syslogs kommen die reels dann vermutlich mit einem switching weniger als bei "Verschlüsselt" ohne CAM Zuordnung aus.

Edit:

1 Dann hätte ich noch einen Schuss ins "Blaue". Ich habe die syslogs ähnlicher _OK und _NOK synchronisiert/gekürzt (u. gerade hochgeladen), um sie in einem diff tool zu vergleichen:

_0211j_nuc_2tun_upd3_ca1_nOK_short1, _0211m_nuc_2tun_upd3_ca1_OK_short1 Fangen mit dem 1. swichting an.

_0211j_nuc_2tun_upd3_ca1_nOK_short2, _0211m_nuc_2tun_upd3_ca1_OK_short2 Fangen mit dem 2. swichting an.

und da sieht man dass im _0211j_nuc_2tun_upd3_ca1_nOK_short2

um 14:26:33 BM2LTSNuc64native-MCLI vdr: [12160] [softhddev]SetPlayMode: 1

zu einem Zeitpunkt passiert wo die 3 ORF PIDs (300x) noch nicht gesetzt sind. Das ist im _0211m_nuc_2tun_upd3_ca1_OK_short2 anders.

2 Kannst du sagen wie man den ncv log ansieht, dass ein nicht dekodierten Strom folgen wird

3 Kannst du sagen wie man dem sys log ansieht, dass ein nicht dekodierten Strom folgen wird

4 Aus welchen Gründen macht vdr/mcli selbständig ein erneutes switching zum aktuellen Kanal

5 Kann/könnte vdr/mcli erkennen dass der Datenstom nicht dekodiert wurde und dann ein erneutes switching auslösen

Danke HelmutB

Es kommt nach dem Umschalten auf ORF2 kein Bild ... auch das syslog fällt kurz aus ... ev liegts auch an mir ?

Die beiden Logs liegen am gleichen PLatz: _nurNCVboot095g_orf2hd_0213a

HelmutB Ich vermute es kommt daher, weil sich die Kanal Daten (PIDs,...) geändert haben (um die Zeit hat orf2OOE ja den Lokalaustieg).

Weil ATV SD läuft. Der ORF1 HD lief 30s und stoppte dann. Nach dem 2. Anwählen lief er dauerhaft.

ORF2HD läuft gar nicht erst los, auch nicht nach erneutem Anwählen ... falls du davon logs möchtest, bitte melden ... dann mach ich das !

Edit:

Ich kann den 30s Hänger auf orf1HD nicht mehr reproduzieren. Hier die logs wo ich den NCV neu gestartet hatte und der orf1HD OK war:

_orf1hd_0213b_

orf2HD läuft nach wie vor nicht.

orf1HD nach ca.20s ...nun doch noch einmal reproduzierbar... ich habe dann ca 20s gewartet und neu angewählt ... dann läuft er wieder

_orf1hd_0213c_

nun läuft auch orf2HD (ich denke dass das ChannelUpdate mittlerweile geschehen ist).

Danke, ich muss jetzt weg ... das war jetzt zu hektisch. Fast du bitte nochmal kurz zusammen mit welchen Einstellungen ich morgen was testen soll.

Guten Morgen HelmutB , 095g, ORF1HD und 2HD OOE von deinem File genommen

Alle 4 ohne CA11 (vdr Standard) nach 20-30s NOK

- ORF2OHD _0214a_ und b hab ich ca. 15s nach Fehler neu angewählt und 20s danach die logs kopiert

- ORF1HD _0214c_ und d sofort nach Auftreten kopiert

Mit CA11:

- ORF2OHD _0214e NOK sofort nach Auftreten kopiert

- ORF1HD _0214f_ OK ca. nach 1min. kopiert

- ORF1HD _0214g_ NOK sofort nach Auftreten kopiert

Im syslog Vergleich _orf1hd_0214f_nuc_2tun_upd3_CA11_OK zu _orf1hd_0214g_nuc_2tun_upd3_CA11_NOK.txt fällt auf:

nur im _OK

09:52:46 BM2LTSNuc64native-MCLI vdr: [10781] Mcli::CAMAvailable: Available CAM [(null)]:0 -> [fe80::208:54ff:fe54:b261]:0

09:52:49 BM2LTSNuc64native-MCLI vdr: ------- Mcli::recv_redirect(1): mcg at ff18:3004:132f:17c8:55f0:8022:730c:6000, receiver 0x55b8b6ad7280 pid 0 id 4911

09:52:49 BM2LTSNuc64native-MCLI vdr: message repeated 5 times: [ ------- Mcli::recv_redirect(1): mcg at ff18:3004:132f:17c8:55f0:8022:730c:6000, receiver 0x55b8b6ad7280 pid 0 id 4911]

in Summe 6x. Beim NOK in Summe 7x.

im _NOK endet es wohl mit dem

09:59:20 BM2LTSNuc64native-MCLI vdr[10781]: Mcli::recv_ts_func: Discontinuity on receiver 0x55b8b6ad7280 for pid 16: 6->8 at pos 0/1

Im Vergleich der ncv Files ist der Auslöser in den NOK Files wohl: ca_del_pid: caid

ca_del_pid: caid = 4911 pid 1920 handle 1
Setting ca dsc. pids (17) on fifo slot 11 PMT (CAM: 0) status to 0 ...
Disabling CAT/EIT pids...
Deleting PMT/CPL (caid 4911 total CAIDS: 1) - sending to CAM...
CAM0: CA PMT DELETED successfully !
ca_del_pid: end !
Highest preference d040 for slot 3

Den "PMT -> ERROR: parse_pmt_ca_desc() : CRC err. crc = 0x2cc94b69" gibt es bei den reels nicht

cinfo wäre es möglich das mcli 095f (nicht g weil da fehlt das retune) auch für BM2LTS 2.94.4/vdr 1.7. zu bauen und HelmutB wäre das sinnvoll ?

- Hängt dann auch die AVG liegt es am mcli. Wenn nicht liegt es am anderen Verhalten des reelvdr (ich denke da an das autom. erneute Anwählen = "switching")