Klaus Schmidinger wrote: > Artur Skawina wrote: >> When a new recording is started vdr touches the .update file so that >> all vdrs using the same /video directory rescan the tree and discover >> the new data. While this makes sense for 'normal' recordings (makes it >> possible to watch an ongoing recording on another vdr), it also >> happens when the cutting process is started. This causes all other >> vdrs to almost immediately reread the /video tree while the disk is >> busy -- both the cutting process and the clients are significantly >> slowed down. >> This change lets the horde of vdrs loose _after_ the cutting is >> finished. Edited recordings appear on other vdrs first when they are >> finished. > > What if a recording starts or is deleted while the cutter is > running? That would also trigger a reread for all other VDRs. > > Besides, the cutter itself as well as the reread of the other VDRs > are done in separate threads. Does this really slow down the > user interface in such a way that's worth this extra handling > (which isn't even complete, see above)? The rescan seems to take up to ~0.5 minute here, and that's with a relatively small video tree. During that time the cutting process is significantly slowed down and browsing the recordings tree on other clients becomes very unintuitive -- some recordings are missing and appear first after tens of seconds, leaving you wondering if they didn't already got deleted etc. I guess the problem doesn't show up on dedicated standalone vdr boxes because the video dir tree usually stays cached in RAM thanks to fadvise. Once you add an NFS client this no longer works (vdr avoids caching on the client, but has no influence on the server). This happens every single time a cutting process is started, but isn't necessary since there's little point in making incomplete edited recordings available to other clients (unlike live recordings). The fact that the problem also happens in other, relatively rare, circumstances isn't really relevant -- there isn't much you can do about needing to update the metadata when it's actually necessary, but that does not mean you can not optimize for the common case. Since you usually end up deleting the original recording after the cutting has ended, doing the rescan late gets you another benefit -- you avoid _another_ cold scan, the tree is already cached; if the update is triggered earlier, while cutting is still going on, the real video data will push the /video metadata out from the caches. I did the change because of performance issues (both slow cutting and an almost unusable (server) vdr box while the concurrent cutting and directory scan is going on). Now that you mention it, i do remember the UI issue mentioned above (plus there are some large UI delays, but i haven't looked into that; they may or may not be related, certainly cutting alone is a factor). Presenting the "old" recordings list while rescanning the updated dir tree would improve the user experience, but i've gotten used to waiting for the recordings to appear and UI issues are not a priority... (or is this already how rescanning works and the delays i was seeing were caused by something else?) artur
