Wer erzaehlt mir das ?

Beitrag von **Space_2063** » Montag 4. März 2002, 18:58

Hi miteinander, ich moechte mal eine Frage haben duerfen

Ich habe gerade das Problem, da ich bei meinem selber kompilierten CDK nach dem Start vom Neutrino immer erst einen Transponder Wechsel durchfuehren muss, bevor Sender gefunden werden. Der erste eingestellte kanal ist "Zur Zeit nicht verfuegbar".

Im Log sehe ich dann

[zapit] Read pat : Connection timeout

Da ich diese Meldung nicht im zapit code gefunden habe - wer (oder besser, welche Routine) erzaehlt mir dies ? Koennte ich testweise irgendwo das Timeout hoeher setzen ?

Danke.

Beitrag von **NoClue** » Montag 4. März 2002, 19:39

Schau mal in pat.cpp nach "Read pat" - den ganzen Ausdruck wirst Du so nicht finden. Dann suchst Du noch nach timout in zapit.cpp -> Die kannst Du mal beide auf 10000 stellen.

NoClue

Beitrag von **Space_2063** » Montag 4. März 2002, 20:24

Danke dir NoClue, werde ich doch gleich mal testen.

Beitrag von **Space_2063** » Montag 4. März 2002, 22:10

Schade, hat nix geholfen, trotz alle timeouts auf 10 sek stehen. Hier nochmal ein Log, falls jemand eine Idee hat. Hochgefahren mit Pro7, danach auf Sat1 gezapt, dann SWR3

Changed to TV-mode
All channels received
receiving bouquets...All bouquets received (27). Receiving channels... receiving
channels for bouquets...........................
[infoviewer]: query epg for >850382< (ProSieben)
dmxdev: set buffer size 40000 -> 60000
[infoviewer]: query epg for >850382< (ProSieben)
[infoviewer]: query epg for >850382< (ProSieben)
[zapit] read Pat: Connection timed out
dmxdev: set buffer size 40000 -> 60000
dmxdev: set buffer size 40000 -> 60000
dmxdev: set buffer size 40000 -> 60000
[zapit] read pmt: Connection timed out
avia_vbi: stop_vtxt (pid = 0xFFFFFFFF)
dmxdev: set buffer size 40000 -> 60000
[infoviewer]: query epg for >85002e< (SAT.1)
[infoviewer]: query epg for >85002e< (SAT.1)
[infoviewer]: query epg for >85002e< (SAT.1)
dmxdev: set buffer size 40000 -> 60000
[infoviewer]: query epg for >85002e< (SAT.1)
[zapit] read Pat: Connection timed out
[infoviewer]: query epg for >16dd1< (SDWEST BW)
dmxdev: set buffer size 40000 -> 60000
[infoviewer]: query epg for >16dd1< (SDWEST BW)
[infoviewer]: query epg for >16dd1< (SDWEST BW)
[infoviewer]: query epg for >16dd1< (SDWEST BW)
dmxdev: set buffer size 40000 -> 60000
[infoviewer]: query epg for >16dd1< (SDWEST BW)
[infoviewer]: query epg for >16dd1< (SDWEST BW)
[infoviewer]: query epg for >16dd1< (SDWEST BW)
dmxdev: set buffer size 40000 -> 60000
[infoviewer]: query epg for >16dd1< (SDWEST BW)
[infoviewer]: query epg for >16dd1< (SDWEST BW)
dmxdev: set buffer size 40000 -> 60000
[zapit] read pmt: Connection timed out
avia_vbi: stop_vtxt (pid = 0xFFFFFFFF)
TSID: 044d

Manchmal ist kurz vorm finden eines Transponder noch eine Meldung vom avia_core zu sehen:

[infoviewer]: query epg for >16dcc< (hessen fernsehen)
dmxdev: set buffer size 40000 -> 60000
[zapit] read pmt: Connection timeavia_vbi: stop_vtxt (pid = 0xFFFFFFFF)
TSID: 044d
[infoviewer]: query epg for >16dcc< (hessen fernsehen)
avia_vbi: start_vtxt (pid = 0x130)
avia_core.c: avia_interrupt: Reserved 01.
[infoviewer]: query epg for >16dcc< (hessen fernsehen)

Interessanterweise hat zapit bei SWR3 auch eine Weile rumgesucht, bis es den Transponder gefunden hat. Wenn es dann endlich einen hat, gibt es keine Probleme beim Zappen mehr.

Beitrag von **obi** » Dienstag 5. März 2002, 02:08

10 sekunden?
also ueberlegt mal, die daten werden hier nicht zu fuss uebertragen, so dass man 10 sekunden auf ne pat warten muesste.

alle tables die man zum zappen braucht sind imho unterhalb einer sekunde zu bearbeiten (alle zusammen)

Beitrag von **Space_2063** » Dienstag 5. März 2002, 09:34

obi, das 10 sekunden zu lang sind, ist mir schon klar. Ich versuchte halt alle Eventuallitaeten auszuschliessen und ein Timing Problem war (ist) halt die einfachste Methode gewesen, um einen ersten Testen zu fahren

Leider hat es halt nicht geholfen. Von daher suche ich halt immer noch

Beitrag von **NoClue** » Montag 11. März 2002, 12:43

schon was gefunden, kommt vorher ein Fehler - läuft edvb/enigma? Verwendest Du den Bootmanager von field, wenn ja, welche Version?

NoClue

Beitrag von **Space_2063** » Montag 11. März 2002, 19:11

NoClue, noch bin ich nicht weiter. Schau mal in den anderen Thread hier im CDK Forum. Dort geht es um das gleiche Problem.

Zu deiner Frage: Bootmanager 3.1.1.343 fuers CDK testen oder cramfs selber bauen und update via telnet. Nimmt sich nicht viel.

Beitrag von **NoClue** » Dienstag 12. März 2002, 09:28

Hi,

ist das der aktuelle CDK oder ist da was modifiziert?
Falls Du versuchst, den aktuellen CDK zu kompilieren, hast Du eventuell mal was ge'tag't? Mach mal ein "cvs update -PdA" - damit werden eventuell vorhandene Tag's gelöscht und saubere Kopien vom CVS-Server gezogen. Änderungen sind dann aber weg.

Danke NoClue, ja ich habe ein paar Sachen verbogen. Ich werde heute abend mal "klar Schiff" machen und einen komplett neuen Versuch starten. Am besten gleich mit den alten glibc.

Beitrag von **NoClue** » Dienstag 12. März 2002, 21:44

Hi,

also die glibc 2.5 läuft bei mir unter cygwin und suse 7.3 problemlos. Aber allerdings hatte ich auch nach der Umstellung auf die neuen binutils komplett neu gebaut -> siehe http://tuxbox.berlios.de/forum/viewtopic.php?t=4381

NoClue

Da du wirklich versucht hast, zu helfen, hier noch mal ein Danke an dich. Siehe anderen Thread. Nach dem ich einen komplett neuen Abzug des CVS mit dem downgrade nach glibc 2.2.3 gemixt habe, funktioniert mein CDK wieder astrein. Nun kann ich weitermachen. Hat sich der Aufwand doch mal gelohnt.