Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unRaid in degraded mode / restarted SageTV and it's deleteing things very rapidly ... could we throttle the media segment deletions? #418

Open
perfessor101 opened this issue Nov 9, 2019 · 4 comments

Comments

@perfessor101
Copy link

Hello,
restarted SageTV today ...
it was 32 bit latest update...
while unraid was throttled and I'm getting mass media deletions ...
unRaid is too slow so it's thinking the files don't exist and deletes them?
I would try starting SageTV again to check it's version ... but it would seem I've lost hundreds if not more recordings. (the directory was over 100,000 files now it's around 71,000 files)

thanks for your time,
Bobby

I'm hoping it's not a hacker removing files ... and SageTV is just removing the rest ...

@Narflex
Copy link
Member

Narflex commented Nov 9, 2019

SageTV will only do this if the filesystem is reporting that the files are zero bytes in size and the root drive (if on Windows) exists (i.e. java.io.isDirectory is true for it). There's no controls to throttle this.

This case really shouldn't occur because if the filesystem says the file exists...it should be able to reports its proper size. There was an issue on Windows with UNC paths where it would report this incorrectly...which was fixed at some point many years ago.

Are you sure it's actually SageTV that's deleting them? If you post your sagetv_0.txt log file I can take a look and see what happened.

@perfessor101
Copy link
Author

perfessor101 commented Nov 11, 2019

I have an unRaid server as my media storage ... SageTV is running on Windows 7 64bit.

Here's the link to a bunch of log files from the last few weeks
on my google drive updated as the names change ... as a log file is renamed to sagetv_1.txt it gets copied then grep'd for "delete", "hang" and "hung for" and those get output to those files for quicker auditing ...

SAGETVSERVER.delete.2019-11-09.txt has the last listed deletions

made a mistake while the array was rebuilding lost most of the november 10th logs and deletions

https://drive.google.com/drive/folders/1BfSmL81QrctQX35oqnxL1aV_ekCkqcIv?usp=sharing

I tried rebuilding the array ... looked okay for a while ... and then SageTV started deleting files again ...
The way SageTV is deleting them they aren't going to the .Recycle.Bin on unRaid or .Recycle.Bin isn't accepting *.mkv, *.ts, *.avi currently ... although it worked in the past.
Other computers having those media files deleted are not getting lost.

... tried moving the last two log files over and unRaid was too busy until rebuilt

@perfessor101
Copy link
Author

don't know if it would help ... but in Windows XP I used the dos "attrib.exe -R -A -S -H mediafile.mkv" command on files before moving them (works on Windows 7 32 and 64 bit also.
it grabs ahold of the file and won't let got until the OS returns a response rather than just timing out ...

possibly check file ... not found
attrib file ... not found
check file ... not found
attrib file ... not found
then delete file if all or first two fail?

@Narflex
Copy link
Member

Narflex commented Nov 12, 2019

I looked at the logs and apparently the file system is reporting them as zero length files...so SageTV thinks they are empty and deletes them. Something is going wrong over SMB in your system that's causing this....I have no idea what that is. There's a note in the code that says back in 2007 there was an issue discovered where it was doing what you describe here because the filesystem was reporting the files did not exist...BUT in that case they reported non-zero size (which is why the zero file size check was added to really make sure the file was empty/non-existent). I'd assume something is wrong with your unRaid server because it's giving out bad information about the filesystem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants