[Wanninger]

...rein interressehalber nochmal die Frage:

Wie war das Livebild von 3Sat HD während der Aufnahme von 3Sat HD noch lief?

-Wanninger

[harpmaster]

hallo claus,
darf ich zum thema cec und pulse eight adapter eine zwischenfrage stellen? habe zwei hdmi kabel gekauft die cec-zertifiziert sind, aber meine ri nicht steuern können. ein kabel hatte ich bereits daheim, da zeigt der tv an, dass ein pulse eight adapter verbunden wurde und mein raspi kann darüber auf allen 4 hdmi-eingängen gesteuert werden. weiss leider nicht mehr wo und was ich da für ein hdmi-kabel gekauft habe, ist ein ednet mit einer art stoffummantelung. worauf muss ich da genau achten? vielen dank ....

[testbert]

Hallo,

ja, das Live-Bild war von 3Sat HD, während die Aufnahme lief.
Das Live-TV-Bild von 3 Sat HD war gewohnt einwandfrei. Die Aufnahme zeigte nach keiner Minute wieder die Artefakte.

[clausmuus]

Damit das steuern per cec funktioniert, muss das meistens erst im TV aktiviert werden. Wenn's nicht klappt, liegt's also für gewöhnich micht am Kabel.

Claus

[harpmaster]

aktiviert habe ich es am fernseher, aber es klappt nur mit diesem öminösem ednet-kabel. mit keinem anderen bisher (3 stück) ...

[Wanninger]

Das deutet aber doch voll auf einen "Bandbreitenengpass" hin, wo und wie auch immer der entsteht.

Wir sprechen hier aber schon von einem RPI-2 mit QuadCore CPU, und nicht von einem RPI-1 B+ (mit microSD)?

Hast Du schon mal den Schreibdurchsatz vom RPI in Richtung SD-Karte, z.B. mit ddrescue getestet?

-Wanninger

[clausmuus]

Wenn es ein Bandbreiten Problem wäre, hätten doch auch die Beiden SD Aufnahmen gestört sein müssen... Es sei denn die SD Sender hatten zum Testzeitpunkt unüblich niedrige Bitraten gesendet.

Claus

[Wanninger]

Von der Logik her gebe ich Dir vollkommen Recht.

Aber ich überlege krampfhaft, wo sonst die Artefaktierung entstehen könnte, wenn das Live-Bild von 3Sat-HD
während der Aufnahme des selben 3Sat-HD jedoch einwandfrei ist. Dann müsste es bereits aus dem VDR heraus,
wenn's auf die SD geht, schon zersägt geliefert werden, oder irre ich mich da?

-Wanninger

[testbert]

Ja, wir reden hier über einen RPI-2 mit QuadCore CPU. Er läuft ohne Übertaktung und meldet auch keine Stromprobleme mittels der bunten Quadrate.
Die MicroSD ist eine Sandisk 128 GB der UHS-1 Klasse.
Es ist ein DVB-S Tuner angeschlossen (TechniSat SkyStar USB HD, Amazon Link: https://www.amazon.de/gp/product/B003Z0ZOLC/ref=oh_aui_detailpage_o05_s00?ie=UTF8&psc=1).
Installiert ist auf dem RPI-2 ein MLD5 im stable-Zweig. Laut Web-Backend sind alle Pakete aktuell. Abseits des aktivierten HDMI-CEC und einem EPG-Zusatzmodul (tvguide) sind keine Pakete außerhalb der Standardinstallation für RPI-Standalone aktiviert. Auch keine Skins oder ähnlicher Schnick-Schnack.
Der RPI führt auch keine sonstigen Aufgaben durch und ist per Ethernet-Kabel in das LAN eingebunden.


ddrescue kann ich gerne ausprobieren, sobald ich zu Hause bin.

[rfehr]

@testbert,

hättest du zufällig mal eine andere SDKarte zur hand, mit der du testen könnteste,
meine Vermutung ist, das es an der SDKarte liegt, da im Live-TV keine Probelme vorhanden sind.
Sondern immer nur die Aufnahmen.

gruß,
  Roland

[clausmuus]

Ich würde auch einen Test mit einer anderen SD-Karte vorschlagen. Außerdem fällt mir ein, das der RPI keine 128GB SD-Karten unterstützt. Keine Ahnung was passiert, wenn man solch eine trotzdem nimmt.
Wenn die Karte zu langsam wäre, was in den beschriebenen Fehlern resultieren würde, dann würde normalerweise ein erhöhter irq oder sirq Wert die Folge sein, was bei Dir aber auch nicht zu trifft. Aufgenommen wird der Selbe Stream, der auch angezeigt wird, also unverändert.

Du kannst auch mal testweise eine Kopie einer größeren Aufnahme (1GB wäre gut) erstellen, und schauen wie lange das dauert. Direkt nach dem Kopieren musst Du dann noch ein "sync" ausführen (und die Zeit dazu rechen), da erst dann alle Daten wirklich geschrieben werden.

Claus

[Wanninger]

Falls Bedarf an den ddrescue Tools besteht, hier ein Archiv mit funktionierenden Binaries für den RPI.

-Wanninger

Nachtrag:

Hab mal ein paar Tests gemacht.

1. Schreiben auf ein NAS via NFSv3

Code: [Select]

mld-163> ddrescue -Df /dev/zero /data/tv/test.bin

GNU ddrescue 1.16
Press Ctrl-C to interrupt
rescued:   432734 kB,  errsize:       0 B,  current rate:    4456 kB/s
   ipos:   432734 kB,   errors:       0,    average rate:    6761 kB/s
   opos:   432734 kB,     time since last successful read:       0 s
Copying non-tried blocks...

2. Schreiben auf die SD-Karte

Code: [Select]

mld-163> /ddrescue -Df /dev/zero /test.bin

GNU ddrescue 1.16
Press Ctrl-C to interrupt
rescued:   104857 kB,  errsize:       0 B,  current rate:     145 kB/s
   ipos:   104857 kB,   errors:       0,    average rate:    1205 kB/s
   opos:   104857 kB,     time since last successful read:       1 s
Copying non-tried blocks...

3. Schreiben auf einen USB-Stick

Code: [Select]

mld-163> /ddrescue -Df /dev/zero /media/usb-sda1/test.bin

GNU ddrescue 1.16
Press Ctrl-C to interrupt
rescued:    93847 kB,  errsize:       0 B,  current rate:     369 kB/s
   ipos:    93847 kB,   errors:       0,    average rate:    2085 kB/s
   opos:    93847 kB,     time since last successful read:       0 s
Cpying non-tried blocks...

Das Ergebnis ist durchaus ernüchternd.

Habe das bisher noch nie getestet bzw. gebraucht, da ich immer auf's NAS schreibe.

Aber die Werte die ich hier erhalte, mit Ausreißern von unter 500kB/s sind schon heftig.
Sowohl auf SD als auch auf Stick. Und Durchschnittswerte von 1...2 MB/s sind auch nicht
gerade der Reißer.

Nachtrag 2:

4. Versuch am BananaPI auf SD und auf SSD via SATA Anschluß

Code: [Select]

| __ )  __ _ _ __   __ _ _ __   __ _  |  _ \_ _|
|  _ \ / _` | '_ \ / _` | '_ \ / _` | | |_) | |
| |_) | (_| | | | | (_| | | | | (_| | |  __/| |
|____/ \__,_|_| |_|\__,_|_| |_|\__,_| |_|  |___|
                                               

Last login: Mon Jun 20 22:05:18 2016 from wslx64100040.ncs-online.prv

Load: 0.01, 0.02, 0.05 - Board: 53.9°C - Drive: sensor / 69Gb - Memory: 803Mb

root@bananapi:~# ddrescue -Df /dev/zero /test.bin
GNU ddrescue 1.19
Press Ctrl-C to interrupt
rescued:   128516 kB,  errsize:       0 B,  current rate:     851 kB/s
   ipos:   128516 kB,   errors:       0,    average rate:    3671 kB/s
   opos:   128516 kB, run time:      35 s,  successful read:       0 s ago
Copying non-tried blocks... Pass 1 (forwards)

root@bananapi:~# ddrescue -Df /dev/zero /home/pi/test.bin
GNU ddrescue 1.19
Press Ctrl-C to interrupt
rescued:   215744 kB,  errsize:       0 B,  current rate:    1310 kB/s
   ipos:   215744 kB,   errors:       0,    average rate:    6345 kB/s
   opos:   215744 kB, run time:      34 s,  successful read:       0 s ago
Copying non-tried blocks... Pass 1 (forwards)

Schaut zwar besser aus, ist aber auch noch nicht der Hit...

[clausmuus]

Du bedenkst aber, dass das vermutlich kByte sind, und nicht kBit. Ist aber trotzdem nicht gerade der Hit...

Claus

[Wanninger]

Ist schon klar, und nicht nur vermutlich, sondern wirklich. Das sind xxxBytes/s.

-Wanninger

[testbert]

So, ich habe nun neu installiert (auf eine andere SD-Karte und testweise den test-release 5.1).
HD Aufnahmen klappen nun auch wieder ohne Probleme. Nun habe ich ein anderes Problem: VDRAdmin ist über MLD-IP:8000 nicht erreichbar. Wo richte ich dies ein / aktiviere es? Aktuell finde ich keinen passenden Menüeintrag.