You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Thomas

Super Moderator

  • "Thomas" started this thread

Posts: 4,237

Location: Ost-Allgäu, Bayern

Occupation: Softwareentwickler

  • Send private message

1

Thursday, December 11th 2003, 8:34am

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.

Source code

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

Thursday, December 11th 2003, 11:20am

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

Friday, December 12th 2003, 12:02am

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/

kls

Master

Posts: 2,629

Location: Mettenheim

  • Send private message

4

Friday, December 12th 2003, 3:36pm

Quoted

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

Posts: 1,997

Location: Wolfsburg

Occupation: Anwendungsentwickler

  • Send private message

5

Friday, December 12th 2003, 6:43pm

Quoted

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.

This post has been edited 1 times, last edit by "Torsten/WarEagle" (Dec 12th 2003, 6:45pm)


baltasar

Intermediate

Posts: 486

Occupation: Schuhverkäufer

  • Send private message

6

Monday, December 15th 2003, 3:50pm

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

Trainee

Posts: 161

Location: Berlin

Occupation: Produkt Manager

  • Send private message

7

Monday, December 15th 2003, 4:42pm

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

This post has been edited 1 times, last edit by "marcoxyz" (Dec 15th 2003, 4:43pm)


Posts: 1,997

Location: Wolfsburg

Occupation: Anwendungsentwickler

  • Send private message

8

Monday, December 15th 2003, 6:14pm

Quoted

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.


Quoted

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

Intermediate

Posts: 486

Occupation: Schuhverkäufer

  • Send private message

9

Monday, December 15th 2003, 9:08pm

Quoted

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.

Quoted


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

Tuesday, December 16th 2003, 9:31am

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

Trainee

Posts: 161

Location: Berlin

Occupation: Produkt Manager

  • Send private message

11

Tuesday, December 16th 2003, 10:10am

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

This post has been edited 1 times, last edit by "marcoxyz" (Dec 16th 2003, 10:11am)


Posts: 1,997

Location: Wolfsburg

Occupation: Anwendungsentwickler

  • Send private message

12

Tuesday, December 16th 2003, 12:42pm

Quoted

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.


Quoted

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.

This post has been edited 1 times, last edit by "Torsten/WarEagle" (Dec 16th 2003, 12:44pm)


Spaceman

Intermediate

Posts: 338

Location: Hessen

Occupation: Dipl. Informatiker

  • Send private message

13

Tuesday, December 16th 2003, 1:02pm

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

Tuesday, December 16th 2003, 1:21pm

Hi,

Quoted

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

Posts: 1,997

Location: Wolfsburg

Occupation: Anwendungsentwickler

  • Send private message

15

Tuesday, December 16th 2003, 1:29pm

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

Trainee

Posts: 161

Location: Berlin

Occupation: Produkt Manager

  • Send private message

16

Wednesday, December 17th 2003, 1:09pm

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

This post has been edited 1 times, last edit by "marcoxyz" (Dec 17th 2003, 1:10pm)


eloy

Trainee

Posts: 151

Location: NRW / Aachen

  • Send private message

17

Wednesday, December 17th 2003, 1:52pm

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

Wednesday, December 17th 2003, 6:15pm

Quoted

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

Wednesday, December 17th 2003, 6:30pm

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

Posts: 3,064

Location: Magdeburg/Wolfsburg

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

  • Send private message

20

Wednesday, December 17th 2003, 7:29pm

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

This post has been edited 1 times, last edit by "Tobias" (Dec 17th 2003, 7:53pm)