Spark (div. Kleinigkeiten)

[dietmarw]

...
Der Doppelpunkt steht soweit ich weiss nicht zur Verfügung (gibts den überhaupt?), wenn dann müsste das in den aotom-Treiber eingebaut werden.

soweit mir zugetragen wurde, wird der in einem anderen image angezeigt.. (weiß aber nicht welches)

[schufti]

naja, in einem "anderen" Image welches aber auf N-HD basiert läuft die Uhrzeit auch im "native" Mode, sichtbar am schnell blinkenden Punkt zw. HH und MM. Diese Betriebsart wäre wohl am besten, da autark und ohne notwendiges Zutun extriger jobs/threads. Das Uhrzeitupdate wirkt auch weniger "auffällig" da nicht die ganze Anzeige flackert sondern nur die sich ändernden Segmente.

ich habe nochmal die lircd.conf für Alien angepaßt, so dass jetzt

TV/SAT den 4:3 Mode
v.format die Auflösung
PICAM das Bildschirmformat

ändern. mit den "alten" Timings und 150/250 in den key-settings läuft es fast optimal.

[martii]

Der Doppelpunkt steht soweit ich weiss nicht zur Verfügung (gibts den überhaupt?), wenn dann müsste das in den aotom-Treiber eingebaut werden.

Die Frontpanel-unterstützte Zeitanzeige mit blinkendem Doppelpunkt bekommst Du beim Setzen der Zeit über den VFDSETTIME ioctl. Siehe z.B. simple_display.cpp im Pingulux-GIT oder fp_control/Spark.c.

Die kurz aufblitzende LED beim Tastendruck der RC:

struct aotom_ioctl_data vfd_data;
vfd_data.u.led.led_nr = 1;
vfd_data.u.led.on = 10; // 100ms
ioctl(aotom_fd, VFDSETLED, &vfd_data);

(->lirc-Patch, evremote2/Spark.c oder lirmp_input.cpp im Pingulux-GIT)

[dietmarw]

hab mir jetzt mal die simple_display.cpp vom pinky und seife nebeneinander gelegt,
aber da übersteigt es meine kenntnisse.
ich kann da zwar z.b. azbox änderungen und abfragen auf display länge <5 zeichen erkennen,
aber eine aktivierung des doppelpunktes z.b. sehe ich in der pinky datei nicht.

[schufti]

wenn ich das richtig interpretiere verhält es sich wie folgt (martii möge mich korrigieren)

in seifes CLCD::showTime wird nach div. Formattierungen der Zeitstring mit display(timestr, false) einfach als Text aufs LED device geschickt --> hier kein Trennzeichen.

in pinkys CLCD::showTime geht der Zeitstring nach div. Formatierungen zuerts per ioctl(fd, VFDSETTIME, &vData) ans LED device (fr schaltet auf "Zeit" --> Trennzeichen) und nur falls das fehlschlägt nach weiterer Umformatierung mit ShowText(buf, false) wieder als Text ans LED device.

Frage an martii: ist CLCD::TimeThread hier eigentlich nur aktiv bis die Zeit einmal erfolgreich per ioctl gesetzt wurde, d.h. der fp zeigt die Zeit danach selbstständig an?

[martii]

Frage an martii: ist CLCD::TimeThread hier eigentlich nur aktiv bis die Zeit einmal erfolgreich per ioctl gesetzt wurde, d.h. der fp zeigt die Zeit danach selbstständig an?

Prinzipiell reicht es, einmal die Zeit zu setzen. Die wird dann, blinkend, mit Doppelpunkt, angezeigt -- aber nur, bis mal was anderes angezeigt wird, dann ist das selbe Spiel nochmal erforderlich. Ich setze die Zeit deshalb vom TimeThread aus neu, wenn einer der folgenden beiden Fälle eintritt:

• - die letzte programmgesteuerte Ausgabe (Kanalname, Volume, whatever) ist hinreichend lang her, dass wieder die Zeit angezeigt werden soll

• - die anzuzeigende Zeit hat sich geändert und es fand keine programmegesteuerte Ausgabe statt

Der TimeThread läuft also immer, sorgt dafür, dass die Nicht-Zeit-Ausgaben wieder verschwinden und hält die Frontpanel-Zeit synchron zur Systemzeit.

Die Verwendung des ioctl() müsste als angenehmen Nebeneffekt haben, dass das auch auf dem Pingulux-Plus-Display ordentlich läuft. Hab ich aber noch nie selbst gesehen.

[mohousch]

wenn ich mich recht erinnern kann, der Timethread ist damals für das LCD der Dbox geschrieben worden, die alten CST hatten auch kein RTC (möge mich ein korrigieren wenn ich mich irre) d.h die Umschreibung, die meisten sh4 Boxes front panel haben selbst ein Uhr, waere nicht sinnvoll dies zu anzeigen statt den CPU im Standby noch mit einem Thread zu belasten.

[martii]

wenn ich mich recht erinnern kann, der Timethread ist damals für das LCD der Dbox geschrieben worden, die alten CST hatten auch kein RTC (möge mich ein korrigieren wenn ich mich irre) d.h die Umschreibung, die meisten sh4 Boxes front panel haben selbst ein Uhr, waere nicht sinnvoll dies zu anzeigen statt den CPU im Standby noch mit einem Thread zu belasten.

Der TimeThread wird (in meiner Version) während des Normalbetriebes für das Zurückschalten auf Zeitanzeige ohnehin benötigt. Den Thread im Standby zu deaktivieren lohnt nicht, der Aufruf erfolgt ohnehin nur alle 60 Sekunden, das geht im Rauschen unter.

[schufti]

so stelle ich mir einen sachlich gehaltvollen Thread vor. Da braucht jetzt keiner stumpf Code kopieren, sondern man kann Vorlagen mit Verständnis angepasst fürs eigene Projekt umsetzen...

Da kann ich mir vorstellen, dass auch seife die paar Minuten bei der nächsten Revision opfert um dieses "eye-candy" an Board zu haben.

[seife]

Es kann gern jeder patches / pull-requests schicken.

Das problem ist, dass es zwei verschiedene git-repos gibt, beide leider IMVHO suboptimal organisiert:
* tdt
* pingulux-git

ich habe mich aus verschiedenen Gründen für tdt als "basis" entschieden. Dummerweise brauchen die "advanced" features aber den aotom aus dem pingulux-git, zumindest wenn ich das richtig sehe. Den immer rüberzumergen ist nun aber halt nicht so ohne. Ich habe das irgendwann mal gemacht, aber seither nicht mehr angefasst. Persönlich finde ich das Display der sparkboxen sowieso maximal nutzlos, insofern will ich da nicht unnötig Arbeit reinstecken.

Aber wer das macht: einfach einen pull-request schicken und ich schau's mir an.

[schufti]

danke für die Anpassungen!

[schufti]

mal wieder was neues ...

mir ist aufgefallen, dass ich Probleme mit abgespeichertem EPG habe, wenn der Pfad auf einem nfs-share liegt, der von Neutrino gemounted wird. Irgendwie dürfte da der mount thread noch nicht fertig sein, wenn der sectionsd das EPG einlesen will (besonders wenn der nfs-server erst die Platte hochfahren muß).

Und ich weiß aus div. Foren, dass ich da nicht der Einzige bin mit dem Problem. Kann man das ev. irgendwie sauber lösen (ohne mount vor Neutrino Start)?

[seife]

Hm, eigentlich wird das einlesen der EPG-daten (in InitZapper()) erst eindeutig nach dem Aufruf von CFSMounter::automount() gestartet.

Mit welchen Optionen mountest du denn die NFS shares? etwa mit "soft"?

[schufti]

rw,tcp,hard,intr,nolock,timeo=10

wie gesagt, wenn die Platte mal läuft geht es immer.
Nur beim ersten Start am Tag so gut wie nie, und natürlich ist dann das Archiv im Eimer ...

ist die index.xml eigentlich notwendig? Kann man nicht einfach alle .xml im Verzeichnis einlesen, dann würde ein Neustart nach "Fehlstart" nicht alle noch vorhandenen Files entwerten.

[seife]

Hm, dann verstehe ich das nicht. Denn mit "hard" sollte der lesezugriff so lange blockieren, bis deine Platte angelaufen ist.

Kannst du mal, wenn die Platte aus ist, probieren was "cat /mnt/foo/epg/index.xml > /dev/null" macht? Also ob da eine (und welche) Fehlermeldung kommt.

Ansonsten im sectionsd.cpp:insertEventsfromFile() mal debugging einbauen, damit du siehst warum genau er das nicht einliest. Evtl. muss dort nur etwas besseres Fehlerhandling eingebaut werden...

[schufti]

ja, das war auch mein Verständnis von "hard". Darum habe ich das damals auch als default bei pinky vorgeschlagen. War dann zwar besser, aber eben nicht zuverlässig.

Werde mal versuchen dem auf den Grund zu gehen, is bloß nich so einfach wenn man jedesmal warten muß bis Platte wieder ausgeht ev. is es ja auch nfs Server der nicht rasch genug reagiert?

[seife]

bei "hard" sollte da nie ein Fehler kommen, es sei denn der mount ist ganz weg oder so, zumindest wenn ich das richtig lese in der doku...
O_NONBLOCK wird auch nicht verwendet soweit ich sehe, also ohne den Fehler zu sehen ist es schwierig das zu debuggen.

[schufti]

Hi,

zum Thema EPG einlesen:
habe das jetzt durch ein paar Tage und etliche Neustarts getestet und in der Tat geht es mit dem "Original" und martiis clone fast zuverlässig. Allerdings gabs ( so ca 1 aus 20) mal nen Aussetzer, aber da muß da Problem irgendwo im Netzwerk liegen (obwohl die Box direkt am NAS hängt).
Das Log zeigt folgendes:

Code: Alles auswählen

seeking to 12f248
....
seeking to 1510c0
seeking to 14f0ac
seeking to 151100
starting /etc/init.d/S56networking ...
Configuring network interfaces... done (continuing in background).
starting /etc/init.d/S60lircd ...
....
[neutrino start] 1869  ->   230 ms
$Id: sectionsd.cpp,v 1.305 2009/07/30 12:41:39 seife Exp $
====> USING SLOW ADDEVENT. export 'NO_SLOW_ADDEVENT=1' to avoid <===
[sectionsd] Caching max 40000 events
[sectionsd] Caching 10 days
[sectionsd] Caching 240 hours Extended Text
[sectionsd] Events are old 180min after their end time
/var/tuxbox/config/zapit/epgfilter.xml: No such file or directory
/var/tuxbox/config/zapit/dvbtimefilter.xml: No such file or directory
/home/evolux/martiis-buildsystem-cs/source/neutrino-hd-td/src/sectionsd/sectionsd.cpp 9245 thread 763360440
/home/evolux/martiis-buildsystem-cs/source/neutrino-hd-td/src/sectionsd/sectionsd.cpp 9259 thread 771749048
/home/evolux/martiis-buildsystem-cs/source/neutrino-hd-td/src/sectionsd/sectionsd.cpp 9284 thread 780137656
/home/evolux/martiis-buildsystem-cs/source/neutrino-hd-td/src/sectionsd/sectionsd.cpp 9346 thread 788526264
....
[neutrino start] 1981  ->  1700 ms
[neutrino start] 1992  ->  1700 ms
[CFSMounter] Mount(0) 192.168.22.131:/mnt/C -> /mnt/nfs
00:36:03.000 [timeThread] - 21.07.2012 00:36:03, tim: Sat Jul 21 00:36:03 2012
00:36:03.000 [timeThread] Time set via DVB(TDT), going to sleep for 5 seconds.
00:36:06.082 [eitThread] skipping to next filter(1) (> DMX_TIMEOUT_SKIPPING 20)
[CFSMounter] FS mount error: "mount -t nfs 192.168.22.131:/mnt/C /mnt/nfs -o rw,hard,tcp,intr,timeo=10,nolock,rsize=32768,wsize=32768"
[neutrino start] 2008  ->  6238 ms

im Prinzip wäre es so alltagstauglich, bloß dass dann immer die index.xml zerschossen ist, ist ärgerlich. Kann man die nicht umgehen und einfach alle .xml files im gegebenen Verzeichniss einlesen die der Namensgebung passen (bzw die Liste so generieren, wenn sie zum Einlesen verwendet wird)? Oder beim Neutrino-Ende nichts rausschreiben, wenn das Einlesen nicht erfolgreich war und eine index.xml existiert?


neue Punkte:
Schon mal versucht, dass Menu auf eine andere Position zu setzen (settings/OSD/menu position)?
Bei mir ist danach das Menu unbedienbar, andere OSD (Infobar, Channellist) funzen.

Der TS-Player friert ein, wenn man versehentlich versucht vor den Anfang zu springen (also z.B. 2x"3" dann 1x"4"). Und ist es viel Aufwand (wie im dBox2 Neutrino) bei zweimal "Info" die Filminfo anzuzeigen?

zuletzt:
was kann die Fehlermeldung bedeuten?
Jan 1 01:00:16 spark-Neutrino-HD user.err neutrino: Config error: unknown option 50 given!

danke und Gruß,
schufti

[martii]

was kann die Fehlermeldung bedeuten?
Jan 1 01:00:16 spark-Neutrino-HD user.err neutrino: Config error: unknown option 50 given!

Ist wohl RefreshDisplay=50 in der /etc/graphlcd.conf. Ich nehm's mal raus ...

[schufti]

ich denke nicht, das die numerischen Defaults hier

Code: Alles auswählen

g_settings.enabled_video_modes[3] = 1; // 720p 50Hz
g_settings.enabled_video_modes[4] = 1; // 1080i 50Hz

hardwareunabhängig sind. Ich denke eine saubere Lösung müßte in etwa so aussehen:

Code: Alles auswählen

g_settings.enabled_video_modes[VIDEO_STD_720P50] = 1; // 720p 50Hz
g_settings.enabled_video_modes[VIDEO_STD_1080I50] = 1; // 1080i 50Hz

und sollte man das nicht zumindest um PAL erweitern, für den Fall der Fälle?

dazu zusätzlich die Fragen:
°) warum sind die Video-SubMenüs "vs_dbdropt_ch" und "vs_videomodes_fw" auf Spark nicht aktiv, generell funktionieren sie ja (zumindest die Videomodes, beim anderen habe ich keinen wirklichen Unterschied ausmachen können). btw: zuletzt war da mal die Auswahl nichts/de-irgendetwas/beide ; was ist da beide? nichts+de-irgendetwas?

°) kann man die dzt. hardcoded Tasten für 4:3 (rc_next) / Format (rc_mode) /Auflösung (rc_previous) Umschaltung nicht ev. auch in das Tasten-Setup aufnehmen? Für eindeutige Tasten (Menu, ok, Vol+/-, 0..9, etc) ist eine fixe Zuordnung ja ok, aber bei anderen Dingen macht es die notwendige Fummelei über neutrino.conf / lircd.conf unsauber. edit: Danke martii

[seife]

dbdropt gibts nicht auf !CS IIRC, und das andere ist einfach noch nicht fertig.

Langfristig will ich das mit der Hardwareabhängigkeit ganz anders lösen (ein objekt in der libstb-hal das alle capabilities der jeweiligen Hardware kennt), aber das dauert halt. Als one-man-show ist das halt darauf beschränkt, was ich so brauche und haben will

[schufti]

darf ich mal nachfragen ob die Probleme mit

°) dem TS-Player (Vorspulen über Anfang hängt box)

°) der Menüposition (Menü wird extrem träge)

bekannt sind, überlesen oder bloß nicht kommentiert wurden?

danke,
schufti

[martii]

Hi Schufti,

°) dem TS-Player (Vorspulen über Anfang hängt box)

kann ich nachvollziehen, aber zumindest von meiner Seite noch keine Fehlerbehebung da.

°) der Menüposition (Menü wird extrem träge)

Das wiederum tritt bei mir nicht auf, zumindest nicht so, dass es aufgefallen wäre.

[seife]

darf ich mal nachfragen ob die Probleme mit

°) dem TS-Player (Vorspulen über Anfang hängt box)

°) der Menüposition (Menü wird extrem träge)

bekannt sind, überlesen oder bloß nicht kommentiert wurden?

bekannt schon, du hast es ja gemeldet, aber ohne Patch dran dauert das halt bis ich dazu komme, mir das anzuschauen.

[schufti]

ok, ev. ist das Menupositionsproblem abhängig von der Bedienung:

gerade probiert: einfach mal alle positionen mit OK-Taste durchdrücken. Mittendrin plötzlich Bildfreez, kein Ton mehr .... nur mehr Zeitlupen OSD ev. Fadig schuld ? teste später.