Beiträge von kls

    Danke für all die Tipps und Hinweise. Ich hätte vielleicht noch dazu sagen sollen, daß natürlich eine Lösung ohne "rooten" angestrebt wird, die "DAU-fähig" sein muss.


    Jedenfalls hat sich meine Einstellung zu Android hierdurch mal wieder bestätigt ;-).


    Klaus

    Hi Rene,


    sorry it's been a while ;-).

    Please take a look at the attached patch.

    I believe the Lock()/Unlock() in cDevice::AttachReceiver() and cDevice::Detach() is superfluous, because the receiver[] list is already protected by mutexReceiver, which is held in both cases. Consequently we need to hold mutexReceiver in cDevice::Action() now, too, but this seems only natural, because now every access to receiver[] is protected only by mutexReceiver, and we totally avoid the deadlock in waiting for the device lock.


    Klaus

    Für einen iPhone-Benutzer ist das ja eigentlich kein Thema: iPhone am Mac anstecken, iTunes macht Backup, fertig!


    Nun fragt mich aber ein Android-Benutzer, wie er denn all die Fotos, Kontakte etc. seines "Samsung G5" auf seinen Windows PC sichern könnte. Eine Suche bei Google zeigt, daß es da wohl ebenso viele verschiedene Methoden gibt, wie es Android Handys gibt ;-). Was ich aber nicht gefunden habe ist, ob es eine einfache und vor allem "idiotensichere" Methode gibt. So nach dem Motto: Handy am PC anstecken, Icon anklicken (falls die entsprechende Applikation nicht automatsich gestartet wird), Backup wird erzeugt, Meldung wenn fertig.


    Dabei sollte das Backup, wenn möglich, inkrementell erfolgen, mit vollständigen Backups in bestimmten Abständen, und dazwischen nur den Änderungen.


    Gibt es sowas?


    Klaus

    Ich bastle hier mit einem VDR auf Basis eines ASRock J3455M Motherboards und damit zeigt mir softhddevice diesen Kanal an ohne abzustürzen. Es geht zwar etwas ruckelig, aber ich habe Bild und Ton. Das Bild erscheint im Fullscreen-Modus wie ein extreeeeeemer Cinemascope-Film, was aber bei der Auflösung kein Wunder ist.


    Ich muß dazusagen, daß ich bisher noch keinerlei Versuche bzgl. Optimierung der Ausgabe gemacht habe, weil ich diesen VDR bisher nur für Testzwecke einsetze.


    Klaus

    Das hier:


    https://www.amazon.de/gp/product/B01NBVTVFZ


    Ich habe bisher noch keine Probleme mit DDBridge beobachtet. Der Dual-CI-Adapter, DVB-S und DVB-T gehen. Allerdings habe ich DVB-S und -T bisher nur kurz probiert, das Meiste mach ich momentan mit SAT>IP. Hab das System hauptsächlich für die Entwicklung von MTD im VDR aufgesetzt. Mittelfristig soll es mal meinen alten VDR mit der TT S2-6400 ersetzen.


    Klaus

    USB-Adapter und Stick kommen zusammen auf unter 20 Euro. Eine SSD dürfte da wohl etwas höher liegen. Und die PCIe-Slots sind alle schon belegt (entweder direkt durch eingesteckte Empfangskarten oder indirekt durch dort montierte, über Kabel mit der DD-Bridge verbundene Karten.


    Ich probiers einfach mal :-).


    Klaus

    Ich bin am überlegen, bei einem neuen VDR mit J3455M Motherboard einen USB 3.0 Stick per Adapter an den internen USB 3.0 Connector zu hängen und darauf das Betriebssystem zu installieren. Die Festplatten (RAID-1) könnte ich dann, wenn keine Aufnahme oder Wiedergabe läuft, komplett abschalten.


    Frage: kann man Linux dauerhaft (24/7) von einem USB-Stick betreiben, oder beansprucht das diesen zu sehr, so daß es zu Ausfällen kommen kann?


    Klaus

    Vielen Dank für die Tipps!


    Ich habe das jetzt mal ausprobiert und mit 'free' beobachtet.


    Also "echo 3 >/proc/sys/vm/drop_caches" löscht die Buffer (allerdings alle, also auch die von anderen Platten).


    "iflag=direct" sorgt dafür, daß gar nicht erst gepuffert wird.


    Somit ist letzteres das, was ich brauche :-).


    Klaus

    Ich sehe gerade, es muss heissen


    hdparm -W 0 /dev/sde


    Code
    1. /dev/sde:
    2. setting drive write-caching to 0 (off)
    3. SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    4. SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    5. SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    6. SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    7. SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    8. write-caching = not supported

    Dem "write-caching = not supported" entnehme ich aber mal, daß die Karte gar kein Write-Caching unterstützt.

    Bleibt die Frage, wie man sicherstellen kann, daß der Kernel nichts puffert, oder wie man nach dem Schreiben dafür sorgen kann, daß ein eventueller Puffer verworfen wird und alle folgenden Lese-Operationen wirklich physikalisch von der SD-Karte lesen.


    Klaus

    Das bezieht sich vermutlich auf ein eventuelles Caching in der SD-Karte selber, oder?

    Code
    1. root> hdparm -W /dev/sde
    2. /dev/sde:
    3. SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 00
    4. write-caching = not supported

    Wichtiger wäre mir zu wissen, ob der Kernel da was cache'd, denn in einem System mit 32GB RAM passt ein 8GB Drive locker rein ;-).


    Klaus