Aufnahmenmenü beschleunigen - so gehts

  • Jaakko Hyvätti hat in der Mailingliste einen Patch für VDR gepostet, der den Aufruf vom Aufnahmen-Menü beschleunigt: http://www.linuxtv.org/mailing…003/12-2003/msg00246.html


    Die Aufnahmen werden vom find-Befehl zusammengesucht, und der bekommt bei vielen Aufnahmen und daher vielen Files arge Probleme, zudem der Filesystemcache nur minimal ist da VDR mit seinen ganzen Streams den Speicher zumüllt :D


    Der Trick besteht bei diesem Patch nun darin, das Hinabsteigen in .del oder .rec Verzeichnisse zu verhindern, somit müssen darin enthaltene Files auch nicht betrachtet werden.



    Viel Spass damit :)

  • hi,
    auch wenn OT ist:
    findet ihr das nicht auch komisch das der vdr so stark auf exterene programme zugreift über popen? kann man das denn nicht auch elegant direkt inline in c++ lösen? da sollte es doch auch funktionen geben mit denen man auf das FS zugreifen kann.
    irgendwie stört mich das (auch wenn die funktionalität gegeben ist)


    p.s. ich maße mir nicht an das besser als kls zu können.

  • Zitat

    Original von slime
    hi,
    auch wenn OT ist:
    findet ihr das nicht auch komisch das der vdr so stark auf exterene programme zugreift über popen? kann man das denn nicht auch elegant direkt inline in c++ lösen? da sollte es doch auch funktionen geben mit denen man auf das FS zugreifen kann.
    irgendwie stört mich das (auch wenn die funktionalität gegeben ist)


    p.s. ich maße mir nicht an das besser als kls zu können.


    Genau genommen greift VDR nur auf ein einziges externes Programm zu,
    nämlich 'find' - weil's halt zum damaligen Zeitpunkt am schnellsten und
    einfachsten zu implementieren war. Aber das wird sich in einer der
    nächsten Versionen ändern...


    Klaus

  • Zitat

    Original von kls
    Genau genommen greift VDR nur auf ein einziges externes Programm zu,
    nämlich 'find' - weil's halt zum damaligen Zeitpunkt am schnellsten und
    einfachsten zu implementieren war. Aber das wird sich in einer der
    nächsten Versionen ändern...


    Klaus


    Hi Klaus :)




    Man sollte eine sache nicht vergessen, bei Find handelt es sich um einen extremst optimierten Code. Wenn man selber etwas programmiert kann es sein, das es einiges langsamer laufen wird als der minimale overhead über system wie er aktuell drin ist.
    sicher könnte man den Code rauskopieren, aber mal ehrlich ist das nicht zuviel Aufwand?
    Wenn man es selber programmiert, denkt man dann an alle spezialitäten wie Links, NFS etc? Das wage ich ehrlich gesagt zu bezweifeln.



    Zum Patch von oben. Ich habe ihn seit der gepostet wurde drauf. Sobald ich wieder unter Linux bin werde ich ihn ausbauen. Mein aufnahmemenu ist dadurch ca. 3mal so langsam beim start geworden. Die idee ist nett, aber scheinbar wird dadurch, das weniger verzeichnisse durchlaufen werden und dadurch weniger io-operationen notwendig sind einiges mehr systemlast erzeugt, wodurch der vorteil dahin ist.


    *edit*
    Hier auch mal der Beleg mit Zahlen:
    time sh 1: (1 ist ein script mit dem neuen befehl)
    real 0m0.263s
    user 0m0.010s
    sys 0m0.040s



    time sh 2: (2 ist ein script mit dem alte befehl)
    real 0m0.191s
    user 0m0.010s
    sys 0m0.030s


    Die Systemlast ist also höher, die Laufzeit länger.

  • Mit einem externen Test kannst du den Effekt innerhalb des vdr nur begrenzt testen.
    Das Problem beim find ist dass der Platten-cache mit streaming daten gefüllt wird, also immer "echte" Plattenzugriffe stattfinden.
    Wenn der patch also einige von den physikalischen ( und langsamen )Plattenzugriffen verhindert kann es sehr viel schneller gehen.

  • Hi Jungs


    Mir ist nicht ganz klar warum nicht der FAM patch Standard ist. Ich hab ihn jetzt seit einigen Monaten Jahr am laufen und er funzt einwanfrei.
    Angeblich soll er irgendwelche Probleme machen mir ist aber bis jetzt nichts dergleichen aufgefallen.


    Ciao Marco


    PS.:
    1.2.6 + Komplett Patch + FAM
    System 6 x 120 GB und Täglich min. 4 Aufnamen Platten immer so um die 70 % genutzt

  • Zitat

    Original von baltasar
    Mit einem externen Test kannst du den Effekt innerhalb des vdr nur begrenzt testen.
    Das Problem beim find ist dass der Platten-cache mit streaming daten gefüllt wird, also immer "echte" Plattenzugriffe stattfinden.
    Wenn der patch also einige von den physikalischen ( und langsamen )Plattenzugriffen verhindert kann es sehr viel schneller gehen.


    Lies dir bitte noch einmal mein Post durch ok? Dann wird dir klar, das ich den Patch bereits einige Zeit am Laufen habe und mit dem Script die Subjektiven eindrücke untermauert habe. Da technisch dasselbe ausgeführt wird, nur intern mit noch mehr drumherum kann man das schon vergleichen.




    Weil der FAM mit nicht-standart-Partitionen heftige Probleme hat, weil der PAtch dazu führt, das aufnahmen teilweise nicht gelöscht werden weil der Patch nicht weiterentwickelt wird, weil fam nicht supportet und weiterentwickelt wird.

  • Zitat

    Lies dir bitte noch einmal mein Post durch ok? Dann wird dir klar, das ich den Patch bereits einige Zeit am Laufen habe und mit dem Script die Subjektiven eindrücke untermauert habe.


    Sorry, habe nicht gesehn dass du es ausprobiert hast. Ich habe den patch auch getestet und habe den Eindruck von einer deutlichen beschleunigung. Evtl. liegt es daran dass mein video Verzeichniss ein NFS Mount ist oder an den Verzeichniss Strukturen.

    Zitat


    Da technisch dasselbe ausgeführt wird, nur intern mit noch mehr drumherum kann man das schon vergleichen.


    Mein Erläuterungsversuche in meinem letzten Post sollten erklären das dem nicht so sein muss. ( aber natürlich sein kann :D )

  • hi
    mein "problem" war es lange zeit dass ich mein 40 GB großes MP3-Verzeichniss als NFS-mount unter /video hatte - das wurde dann immer komplett mitdurchsucht...


    Das das mein Fehler war habe ich aber erst nach langer zeit "zufälligerweisse" gelesen....


    Jetzt geht das ganze superschnell... (nachdem ich /mp3 ins root gemountet habe)


    vielleicht haben ja auch noch andere den selben Fehler gemacht...


    gruß
    dbox.network

  • Hi Thorsten




    Mit nicht Standard Partitionen meinst du warscheinlich vFat. Ok das kann sein aber da wird sich sicherlich ein Workaround finden.
    Das Verzeichnisse nicht ordentlich gelöscht werden liegt kann ich bei mir nicht nachvollziehen (es sei denn man benutzt vdrconvert und löscht nicht den toten sysmbolischen link auf das erstellte Image ;-)).
    Und das der FAM nicht supportet und weiterentwickelt wird kann ja nun nicht wirklich das Problem sein. Wenn der als Standard für die Beschleunigung des Menüs verwendet würde währe er auch wieder gepflegt und supportet.
    Für Leute mit sehr viel Speicherplatz währe ne Setup-Funktion "enable FAM" ideal.


    Ciao Marco

  • Zitat

    Original von marcoxyz
    Mit nicht Standard Partitionen meinst du warscheinlich vFat. Ok das kann sein aber da wird sich sicherlich ein Workaround finden.


    ich meine vfat, fat, nfs, ntfs, smb und reiserfs, denn mit denen gab es probleme.
    Bei ext2 und ext3 lief es ok.



    Zitat

    Original von marcoxyz
    Und das der FAM nicht supportet und weiterentwickelt wird kann ja nun nicht wirklich das Problem sein. Wenn der als Standard für die Beschleunigung des Menüs verwendet würde währe er auch wieder gepflegt und supportet.


    Wieso so sicher? FAM ist ein externes Tool, das mit vdr nix zutun hat, es wird von externen entwicklern erstellt und die haben auf ihrer Homepage vor ca. 1 oder 2 Jahren geschrieben, das sie es nicht weiterentwickeln. Wenn diese Leute nicht rein zufällig einen vdr anschaffen, dann glaube ich nicht, das die plötzlich wieder Lust bekommen.

  • Hi,


    Zitat

    FAM overview
    URL: http://oss.sgi.com/projects/fam/ 
    GUI tools should not mislead the user; they should display the current state of the system, even when changes to the system originate from outside of the tools themselves. FAM helps make GUI tools more usable by notifying them when the files they're interested in are created, modified, executed, and removed.


    Please use the links on the left-hand side of this page to navigate the FAM Web pages.


    Fam-Projektpage


    imho ist FAM sowas ähnliches wie ein "Directory-cache".
    Wenn du nach FAM-patch suchst findest du noch einiges mehr...


    Gruß
    dbox.network

  • Was mich an der Seite gerade verwundert ist, das die letzte Version letzten Monat erschienen ist.
    Zwischendurch hieß es dort mal entwicklungsende, darüber wurde an z.b. in der ML diskutiert was man als alternativen nehmen könnte.
    Scheinbar haben die das Projekt wieder aufgegriffen. interessant.

  • Hi,


    in der VDR Mailinglist gab's im Oktober auch schon eine Diskussion dazu.
    Hier ist der Startpunkt der Diskussion. Eine der Loesungen verwendet einen
    Kernel-Patch zur Vermeidung des Cachings der Videodaten.
    Habe ich bei mir eingebaut und funktioniert auch.
    Das Recordings-Menue wird schneller. Ob's fuer alle Ansprueche
    schnell genug ist (insbesondere bei vollen Platten) ist sicher Geschmackssache.


    Gruss,

    VDR1: MSI-6368, P3 Celeron 700MHz, 320MB, Samsung 160GB, Nexus-S 2.1, Nova-S, IR Selbstbau, LinVDR 0.6, vdr-1.3.27
    VDR2: ASUS Pundit, P4 Celeron 2.4GHz, 256MB, Samsung 120GB, Nexus-S 2.2, SkyStar2, IR Selbstbau, LinVDR 0.6, vdr-1.3.27


  • genau das probleem habe ich :] , nur nicht mit 40 aber mit 80 GB :D:D Danke fur den tip, muss mir die partitionierung noch mal uberdenken.


    Ycat

  • hi


    ycat : bevor du die platte umpartitionierst müsste auch folgendes schema gehen:


    partition als /irgendwas mounten. darunter /video und /mp3 etc anlegen.
    in root statische links auf anlegen:
    /video --> /irgendwas/video
    /mp3 --> /irgendwas/mp3


    gruß
    dbox.network

  • Nochwas: Wo finde ich den aktuellen FAM Patch????
    Die HP vom FAM Projekt habe ich schon ....



    edit: oki, www.akool.de .... gefunden ;)


    grüsse
    tobias

    :vdr1 VDR User #626:fans 
    VDR II: YeongYang A106, Fusi D1522, Celeron 2GHz, Frontend per DVB-s FF, 2xDVB-c, ATRIC-IR, YaVDR 0.3a
    VDR III HDTV: Inter-Tech 2008V mit iMonLCD, Atric, ASRock Extreme3 770 AM3, AMD Sempron 140 1x 2.70GHz AM3, 1,5TB WD15EADS, 2TB WD20EARS, 2x4GB DDR3-1600, NVidia GT520 passiv, 3x DVB-c, YaVDR 0.5 @ Samsung PS-50B550

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von Tobias ()