Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: VDR Portal. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

Thomas

Super Moderator

  • »Thomas« ist der Autor dieses Themas

Beiträge: 4 238

Wohnort: Ost-Allgäu, Bayern

Beruf: Softwareentwickler

  • Nachricht senden

1

Donnerstag, 11. Dezember 2003, 08:34

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/mailinglists/vdr/…3/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.

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
--- old/vdr-1.2.6/recording.c	Sat Nov  8 17:25:35 2003
+++ vdr-1.2.6/recording.c	Wed Dec 10 09:42:34 2003
@@ -46,7 +46,7 @@
 #define SUMMARYFILESUFFIX "/summary.vdr"
 #define MARKSFILESUFFIX   "/marks.vdr"

-#define FINDCMD      "cd '%s' && find '%s' -follow -type d -name '%s' 2> /dev/null"
+#define FINDCMD      "cd '%s' && find '%s' -follow -type d -name '%s' -print -prune -o -follow -type d -name '%s' -prune 2> /dev/null"

 #define MINDISKSPACE 1024 // MB

@@ -621,7 +621,7 @@
   Clear();
   bool result = false;
   char *cmd = NULL;
-  asprintf(&cmd, FINDCMD, VideoDirectory, VideoDirectory, Deleted ? "*" DELEXT : "*" RECEXT);
+  asprintf(&cmd, FINDCMD, VideoDirectory, VideoDirectory, Deleted ? "*" DELEXT : "*" RECEXT, Deleted ? "*" RECEXT : "*" DELEXT);
   FILE *p = popen(cmd, "r");
   if (p) {
      char *s;


Viel Spass damit :)

yaVDR 4, 3.5TB, Antec Fusion Remote, Mystique SaTiX-S2 V2 CI Dual, GF220GT+VDPAU, 1080p Display mit Slimes Atmolight :strike1
Geblogge über dies und das

2

Donnerstag, 11. Dezember 2003, 11:20

hallo,
danke fuer die Info,
werde vdr mal damit patchen.
Auf der Page von Jaakko Hyvätti My DVB/VDR changes and experiences
gibts das diff
auch als Direktdownload , nennt sich prune.diff ,
da kann man sich dann das 'copy & paste' ersparen .
mfg

3

Freitag, 12. Dezember 2003, 00:02

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.
Meine Homepage mit VDR-Projekten: http://ca.rstenpresser.de/~cpresser/

4

Freitag, 12. Dezember 2003, 15:36

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
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer
Mach mit beim VDR User Counter!

Beiträge: 1 997

Wohnort: Wolfsburg

Beruf: Anwendungsentwickler

  • Nachricht senden

5

Freitag, 12. Dezember 2003, 18:43

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.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Torsten/WarEagle« (12. Dezember 2003, 18:45)


baltasar

Fortgeschrittener

Beiträge: 487

Beruf: Schuhverkäufer

  • Nachricht senden

6

Montag, 15. Dezember 2003, 15:50

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.

marcoxyz

Schüler

Beiträge: 161

Wohnort: Berlin

Beruf: Produkt Manager

  • Nachricht senden

7

Montag, 15. Dezember 2003, 16:42

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

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »marcoxyz« (15. Dezember 2003, 16:43)


Beiträge: 1 997

Wohnort: Wolfsburg

Beruf: Anwendungsentwickler

  • Nachricht senden

8

Montag, 15. Dezember 2003, 18:14

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.


Zitat

Original von marcoxyz
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

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.

baltasar

Fortgeschrittener

Beiträge: 487

Beruf: Schuhverkäufer

  • Nachricht senden

9

Montag, 15. Dezember 2003, 21:08

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 )

10

Dienstag, 16. Dezember 2003, 09:31

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

marcoxyz

Schüler

Beiträge: 161

Wohnort: Berlin

Beruf: Produkt Manager

  • Nachricht senden

11

Dienstag, 16. Dezember 2003, 10:10

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

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »marcoxyz« (16. Dezember 2003, 10:11)


Beiträge: 1 997

Wohnort: Wolfsburg

Beruf: Anwendungsentwickler

  • Nachricht senden

12

Dienstag, 16. Dezember 2003, 12:42

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.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Torsten/WarEagle« (16. Dezember 2003, 12:44)


Spaceman

Fortgeschrittener

Beiträge: 340

Wohnort: Hessen

Beruf: Dipl. Informatiker

  • Nachricht senden

13

Dienstag, 16. Dezember 2003, 13:02

Was ist denn FAM ?
P5N7M / 2GB RAM / E5300 / 320 GB 2,5" / yaVDR 0.5 / 2x TT S2-1600 /eVii S471 / softhddevice / Sony KDL-46W5500 / 50Hz / Onkyo TX-SR508

14

Dienstag, 16. Dezember 2003, 13:21

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

Beiträge: 1 997

Wohnort: Wolfsburg

Beruf: Anwendungsentwickler

  • Nachricht senden

15

Dienstag, 16. Dezember 2003, 13:29

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.

marcoxyz

Schüler

Beiträge: 161

Wohnort: Berlin

Beruf: Produkt Manager

  • Nachricht senden

16

Mittwoch, 17. Dezember 2003, 13:09

Wie siehts denn mit der Lizenz für den FAM-Server aus? Open Source ist er ja. Wär doch was von da aus weiterzumachen.

Ciao Marco

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »marcoxyz« (17. Dezember 2003, 13:10)


17

Mittwoch, 17. Dezember 2003, 13:52

RE: Aufnahmenmenü beschleunigen - so gehts

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

18

Mittwoch, 17. Dezember 2003, 18:15

Zitat

Original von dbox.network
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


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

19

Mittwoch, 17. Dezember 2003, 18:30

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

Tobias

Erleuchteter

Beiträge: 3 102

Wohnort: Magdeburg/Wolfsburg

Beruf: Dipl.-Wirtsch.Inf, Spez. Data-Warehousing - Business Intelligence

  • Nachricht senden

20

Mittwoch, 17. Dezember 2003, 19:29

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 Homepage: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« (17. Dezember 2003, 19:53)


Immortal Romance Spielautomat