If <AutoRemoveMissingRecordings> is true, when will the removal take place? I moving stuff around and exporting/editing/importing and the old entries are still in the database - when or what starts the cleanup running?
thanks
It does this whenever it needs to load the recording list (like going the recordings screen, or tv guide). With this setting enabled, when it loads the recording list from the database, it does a double check if the file exists on disk, and if not, removes the entry from the database.
Thanks the very prompt response.
Ah, I must have misunderstood how it worked.
I moved my recordings from D: to F: and changed the recordings directory to F: at the same time and stopped/started the service expecting that the database entries would be removed, but they were not removed. Trying to play them did nothing as expected.
So I changed the recordings directory back to D: and the entries were removed automatically.
From the above it looks like the drive letter in the database is not checked when auto removal takes place.
Anyway, it is empty now, all ready for an import after editing the drive letter.
thanks
martint123 Wrote:Thanks the very prompt response.
Ah, I must have misunderstood how it worked.
I moved my recordings from D: to F: and changed the recordings directory to F: at the same time and stopped/started the service expecting that the database entries would be removed, but they were not removed. Trying to play them did nothing as expected.
So I changed the recordings directory back to D: and the entries were removed automatically.
From the above it looks like the drive letter in the database is not checked when auto removal takes place.
To be clear:
ie, when it loads the recordings list from the database, and it says "D:\Recordings\Something.ts", then it'll ask Windows if it has a "D:\Recordings\Something.ts" file. If Windows says it doesn't exist, then it's deleted from the database.
sub Wrote:To be clear:
ie, when it loads the recordings list from the database, and it says "D:\Recordings\Something.ts", then it'll ask Windows if it has a "D:\Recordings\Something.ts" file. If Windows says it doesn't exist, then it's deleted from the database.
Sorry to disagree, but that isn't how it appeared to happen. It would appear not to remove them if they exist in the directory pointed to by the recordings directory.
These are the steps I took.
stop service
Cut and paste recordings directory and all subdirs from D: to F: (all gone from D
Change default recordings directory from D: to F:
Set autoremove in config.xml to true
start recording service and npvr
Recordings still showing. Trying to play one fails.
Ask question in this thread as to when the cleanup takes place.
stop service
change default recordings directory back to D:
start service an npvr - recordings gone.
change default back to F: and import the old export - all good.
The rule is a little more complicated than my description. There is one more important aspect. If it cant find the directory that the recording was originally in, or it's parent, then it doesn't delete it - on the assumption the user is currently messing around with their recording directories, or they record to a network share which is currently not available. This extra rule was put in to avoid these common scenarios which would often lead to posts on the forum about recordings being unexpectedly deleted.
So, in your case it probably came down to how much of the branch you tried to move.
sub Wrote:So, in your case it probably came down to how much of the branch you tried to move.
Right, that's it then as I cut and pasted the base recording directory. Now you mention it, I recall the change to preserve the data if a share was off line - an excellent change in itself. Sorry to have troubled you, it's difficult for us mere mortals to keep track of all the improvements
Graham Wrote:This may be relevant ... I suspect that it's mostly to do with network shares and disappearing drive mappings but it may apply here.
<NoRemoveWhenTreeMissing> I think you're right Graham, the circumstances are the same as a none-found root recording directory. A quick search doesn't reveal any real mention of it, but now you have mentioned it, I'm sure I recall some chat when/why it was introduced.