[gkd-berlin]

Hallo Claus,

so, jetzt habe ich es auch mitbekommen.

Die Aufwachzeit wird nur bei Poweroff in den RTC geschrieben. Ein Reboot reicht nicht.

Im OSD wird als Timer 4:15 Uhr angezeigt. Im RTC steht 4:13 Uhr. Die 2 Min sind für das Hochfahren vorgesehen.
Datum ist auch richtig gespeichert.
Nur der Wochentag ist noch falsch. Ist mir aber egal, da ich den nicht auswerten werde.

So das war's wohl von Deiner Seite. Herzlichen Dank für Deine Schnelligkeit und Mühe.
Nun muß ich wieder in die Programmierung reinfinden. Das Projekt liegt schon seit Jan. 14 auf Eis.

Gruß Gerhard

[clausmuus]

Hi,

den Wochentag habe ich geändert (hoffentlich richtig )

Sehe ich das richtig, das Du den Ton über hdmi ausgibst und auch der TV per hdmi angeschlossen ist?
Bitte teste noch mal mit einem älteren Image ob da der Ton noch immer funktioniert, und wenn ja, sage mir möglichst genau seit wann der Ton nicht mehr geht.

Claus

[gkd-berlin]

Hallo Claus,

ja, den Ton gebe ich über HDMI aus. Der TV ist per HDMI angeschlossen.

Die letzte funktionierende Version: 18MLD-5_customized_2016.01.02-169+1365.9-c8Hngb_armhf-rpi.tgz

Der Ton fehlt ab Version: 19MLD-5_customized_2016.01.03-169+1366.2-ZNl1Nh_armhf-rpi.tgz
                                         20MLD-5_customized_2016.01.03-169+1366.3-b7yIyS_armhf-rpi.tgz
                                         21MLD-5_customized_2016.01.03-169+1366.4-anK20L_armhf-rpi.tgz

Den Wochentag in der RTC werde ich mit der nächsten, hoffentlich wieder mit Ton, Version testen.

Gruß Gerhard

[clausmuus]

OK, Sound sollte jetzt wieder gehen. Da wurden einige rpi1 Pakte (unter anderem das rpihddevice Plugin) nicht hochgeladen. Somit war auf Deinen letzten Images eine ältere nicht zum VDR passende Version gelandet.

Claus

[gkd-berlin]

Hallo Claus,

Test: 22MLD-5_customized_2016.01.04-169+1367.1-hlnTao_armhf-rpi.tgz

Du darfst Dir, mal wieder, kräftig auf die Schulter klopfen.

Der Ton ist wieder da. Der Rest funktioniert auch.
Habe nichts mehr zu meckern gefunden.

Die RTC funktioniert bestens. Timer = 4.1.16 um 19:50 Uhr gesetzt.

Das konnte ich auslesen:

Code: [Select]

  8        9      10      11      12      13      14
Sek      Min     Std     WT      Tag     Mon     Jahr
0x00     0x48    0x19    0x02    0x04    0x01    0x16

Aufwachzeit: 0x04.0x01.0x16 um 0x19:0x48
Ist noch in Hex-Schreibweise, aber ok.

Danke und Gruß Gerhard

[gkd-berlin]

Hallo,

Test: 23MLD-5_customized_2016.01.05-169+1388.2-0HGg42_armhf-rpi.tgz

- System ok
- RTC       ok

keine Fehlermeldungen in den Log´s.

So macht das Testen Spaß.

Gruß Gerhard

[clausmuus]

Wegen Hex Schreibweise:

Ein 16 Für das Jahr ist in Dezimal Schreibweise "16" und in Hex "0x10" es muss aber eine "0x16" in die Speicherstelle geschrieben werden, also nicht die 16 in Hex umgerechnet, sondern einfach der String "16" mit nem "0x" davor für Hex Schreibweise...

Claus

[gkd-berlin]

Hallo Claus,

Wegen der Schreibweise. Ich sehe das so:

Die Speicherstellen in der RTC sind BCD-codiert. D. h es werde die beiden Halbbytes für die Zahlen 0 - 9 verwendet.

Das paßt genau mit der Hex-Schreibweise zusammen. Auch hier werden 2 Halbbytes für die Zahlendarstellung genutzt.

Ich kann z.B. in die Speicherstelle 0 (Sek.) der RTC mit i2cget -y 1 0x68 0 0xff schreiben. Das macht nur keinen Sinn, da es in der BCD-Codierung keine Zahlen > 9 gibt.

i2cget -y 1 0x68 0 liest die Sekunden, z.B. 0x23, in Hex-Schreibweise aus. Das ist identisch mit der BCD-Codierung für 23.
Man kann die Hex-Schreibweise nutzen, darf aber den gültigen Wertebereich der BCD-Codierung (0-9) und der Uhr nicht überschreiten.

Ich könnte so in die Adr. 1 (Std.) auch eine 25 schreiben. Ist aber auch falsch, da die Stunden nur bis 23 gehen.

Ich hoffe, ich habe mich einigermaßen verständlich ausgedrückt.

Gruß Gerhard

[clausmuus]

Danke für die Erklärung. An eine BCD Kodierung hatte ich dabei nicht gedacht. So macht das aber wieder Sinn.

Claus

[gkd-berlin]

Hallo,

Langzeittest der MLD-5.0.0.........armhf-rpi

Seit dem 26.12.15 befasse ich mich wieder intensiver mit der MLD für den RPI.

Dabei ist mir aufgefallen, daß sich der VDR sporadisch aufhängt.

In der messages steht nur noch sowas:

Code: [Select]

Jan  6 16:31:53 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:53 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:53 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16382] ERROR: TS packet not accepted in Transfer Mode
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.debug vdr: [16374] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
Jan  6 16:31:54 (none) user.err vdr: [16372] rpihddevice: OmxError(InsufficientResources)
In /var/log/vdr steht das:

Code: [Select]

Segmentation fault
VDR exits at Mi Jan  6 16:30:18 CET 2016
VDR exits at Mi Jan  6 16:33:55 CET 2016Das Bild ist schwarz und er Ton ist nur noch in Fetzen zu hören.
Weitere Tastendrücke auf der FB werden nur in größeren Abständen (3-10 Sek.) angenommen.

Ausgelöst wird diese "Macke" durch drücken einer Taste auf der FB. Z. B. Menü, Auf, Ab oder die Zifferntasten.

Ein "Restart vdr" behebt den Fehler wieder. Aber, er kommt wieder.

Der Fehler trat schon nach 3 Minuten aber oft erst nach 1- 2 Stunden auf.
Die CPU-Temperatur steigt bei mir nie über 47 °C.

Ich habe das schon einmal hier angesprochen.
Da war ich noch der Meinung, das es am "sterbenden" Netzteil lag.
Inzwischen wird der RPI von einem 5V / 3A-Netzteil versorgt. Deshalb möchte ich einen Netzteilfehler ausschließen.

Gruß Gerhard

Edit: Der Fehler tritt auch bei stark einfallenden Sendern auf.

[gkd-berlin]

Hallo,

Test: 24MLD-5_customized_2016.01.07-171+1417.1-WvWR0X_armhf-rpi.tgz

auch hier, wie bei der x86.ISO, keine Einwände.

Gruß Gerhard

[gkd-berlin]

Hallo,

Test: 25MLD-5_customized_2016.01.08-171+1413.1-GqwGuM_armhf-rpi.tgz

alles i. O.

Gruß Gerhard

[gkd-berlin]

Hallo,

Test: 26MLD-5_customized_2016.01.09-171+1413.9-dC75J2_armhf-rpi.tgz

nix gefunden. Alles ok.

Gruß Gerhard

[gkd-berlin]

Hallo,

Test: 27MLD-5_customized_2016.01.10-171+1415.4-yNDO27_armhf-rpi.tgz

wieder nichts gefunden!

@Claus:
Wenn ich die RTC nach dem ein Timer gesetzt wurde extern auslese, erhalte ich diese Ausgabe:

Code: [Select]

RTC              Sek     Min     Std     WT      Tag     Mon     Jahr    CRTL

Adr        :      8       9      10      11      12      13      14
Aufwachzeit:     00      53      03      02      11      01      16

Adr        :      0       1       2       3       4       5       6       7
Datum      :     33      05      16      01      10      01      16      03

Aufwachzeit:     11.01.16 um 03:53

Systemzeit :    So Jan 10 17:05:33 CET 2016Dabei fällt auf, die hwclock steht auf UTC. Adr. 0 - 7.
Um die Aufwachzeit mit der hwclock-Zeit korrekt vergleichen zu können, müßte ich zuerst die hwclock von UTC nach CET konvertieren. Zusätzlich kommt noch der Schwachsinn mit der Sommerzeit.
Ich wünschte mir, daß in der hwclock CET steht. Dann könnte ich direkt Aufwachzeit und hwclock-Zeit vergleichen. Geht das?
Wenn nicht, hat jemand einen Algorithmus zur Konvertierung von UTC in CET mit Sommerzeit.

Gruß Gerhard

[clausmuus]

Kein Problem, der Timer sollte jetzt auch in utc gespeichert werden. Das hatte ich übersehen.

Claus