Zapit bleibt hängen ?

[ckm]

Hi,

ich habe hier das Problem, das mit Neutrino immer wieder mal (ca. 1 -2 x am Tag) Bild und Ton stehen bleiben und die Box dann neu gestartet werden muss.
Im Log ist dann beim Umschalten nur folgendes zu sehen.

[dmx.cpp:read:184] read(fd, buf, n): Connection timed out
zap failed!
[dmx.cpp:read:184] read(fd, buf, n): Connection timed out
zap failed!

Auf dem Bildschirm kommt Kanal zur Zeit nicht verfügbar.

Das passiert sowohl mit den Snapshots wie auch mit dem Image vom 22.07
getestet sind auch interne wie externe Ucodes. Aktuelle avia600.ux...

Empfangsqulität ist gut.
Box ist eine Philips 2xI mit avia600.
Passiert egal welches Programm eingeschaltet ist.
Mit Betanova keine Probleme, aber wer will das schon benutzen.

Hat jemand eine Idee den Fehler einzukreisen ?

Gruß
Carsten

[obi]

probier 22.7. mit ucode_B107 oder HEAD mit ucode_001A.
das hat absolut nichts mit zapit zu tun.

[ckm]

Hat eventuell jemand mal eine PM mit dieser Version 001A für mich ?

Gruß
Carsten

[kerlimann]

HEAD mit ucode_001A.

naja, mit ucode 001A passiert das tatsaechlich nicht, dafuer bleibt dann beim zappen der screen schwarz. dieses problem nervt mich auch seit wochen.
im endeffekt habe ich mich fuer die ucode001a entschieden, das erspart den neustart der box, und es bleibt beim mehrmaligen hin/her zappen.

hast du einen tip, was genau sich da verabschiedet, bei diesem "kanal nicht verfuegbar", so das man dies neu starten koennte? ich spinn mir mal was zusammen:

wenn die dmx.cpp doch weiss, das "kanal nicht verfuegbar" ist (immerhin gibt sie das ja aus), koennte man nicht eine funktion implementieren, so das irgendwas neu gestarted wird, was dieses verursacht? zapit restarten waere ja simpel, aber das isses ja leider nicht.

[Nico 77]

Kerlimann da muss ich dir zustimmen, das wäre echt ein Fortschritt, zumal es in anderen bereichen Sachen gibt die diesem "Dilämmer" schon ganz Ecke näher sind. Versuche auch fast jeden Tag in dieser Sache einen Schritt weiterzukommen,nur ist ja alles nicht einfach.

[obi]

nein, dann ist der gtx/enx gecrasht. das read timeout an sich sagt das aber nicht aus. es gibt auch kein register wo drin stuende, dass er gecrasht sei.

[kerlimann]

probier 22.7. mit ucode_B107 oder HEAD mit ucode_001A.
das hat absolut nichts mit zapit zu tun.

hmm, waere das einen versuch wert, in einem aktuellen head die driver vom 21.7ten auszuchecken, compilen, und gucken ob geht? koenntest du damit das problem vielleicht einkreisen? oder ist das weder ein zapit noch ein driver problem?

[Sepp776]

@obi: Ich hab mal testweise beim Umschalten ein avia_gt_enx_init() eingebaut. Aber damit lässt sich der Chip nicht wieder zum leben erwecken.
Hast du nicht nen Vorschlag wo man mal rumprobieren könnte?

CU,
Sepp.

[obi]

@kerlimann
das 22.7. image ist meines wissens api v1. macht also wenig sinn. was eigentlich probieren?

@Sepp776
vielleicht steh ich aufm schlauch.. aber woran erkennst du exakt einen senderwechsel im treiber? und was initialisierst du alles?

[Sepp776]

vielleicht steh ich aufm schlauch.. aber woran erkennst du exakt einen senderwechsel im treiber? und was initialisierst du alles?

Ich hab das in die avia_av_napi.c eingebaut, beim VIDEO_PLAY (also immer wenn ein Playback gestartet wird). Aber das funktioniert nicht so recht. Kriege jetzt gar kein Bild. Ist wohl nicht genug initialisiert Aber irgendwie muss man das Ding doch wieder zum Laufen kriegen *grummel*