Hi,
I just experienced weird problem. My hard drive became 100% full.
But I noticed that there are tons of .del directories, some dating from months ago.. VDR hasn't removed them! What could cause this?
I see entries in log: low disk space while recording, trying to remove a deleted recording... Jan 16 08:23:06 puucee vdr: [30504] removing recording xxx.del
And these recordings ARE removed really. But the normal background cleaning does not happen.
This is somehow related to the fact that I now have Plex Media Server sitting on the VDR recordings directory. But still I could remove the .del directories easily from the command line. After manually deleting them, disk is now only 85% full.. And that's 4TB drive. :) So there were quite a bit of .del directories.
On 16.01.2018 19:44, Teemu Suikki wrote:
Hi,
I just experienced weird problem. My hard drive became 100% full.
But I noticed that there are tons of .del directories, some dating from months ago.. VDR hasn't removed them! What could cause this?
I see entries in log: low disk space while recording, trying to remove a deleted recording... Jan 16 08:23:06 puucee vdr: [30504] removing recording xxx.del
And these recordings ARE removed really. But the normal background cleaning does not happen.
This is somehow related to the fact that I now have Plex Media Server sitting on the VDR recordings directory. But still I could remove the .del directories easily from the command line. After manually deleting them, disk is now only 85% full.. And that's 4TB drive. :) So there were quite a bit of .del directories.
Do you have anything going on that causes frequent "user ineraction" with VDR?
Try adding some debug output to RemoveDeletedRecordings() and maybe also to cRemoveDeletedRecordingsThread::Action() (both in recording.c) to find out what might be causing this.
Klaus
Klaus Schmidinger kirjoitti 17.01.2018 klo 11:59:
On 16.01.2018 19:44, Teemu Suikki wrote:
Hi,
I just experienced weird problem. My hard drive became 100% full.
...
This is somehow related to the fact that I now have Plex Media Server sitting on the VDR recordings directory. But still I could remove the .del directories easily from the command line. After manually deleting them, disk is now only 85% full.. And that's 4TB drive. :) So there were quite a bit of .del directories.
Do you have anything going on that causes frequent "user ineraction" with VDR?
I had a similar problem some time ago (I don't remember how many years, but with vdr 2.2.0). I reported on this mailing list then, but I did not find that email with a short search, now.
My video directory is nfs-mounted to a raspberry pi running another vdr. In my case, I have not changed the configuration in any way, but despite of daily usage, this has not reoccurred. So either some other patch fixed the problem for me, or this is some extremely rarely happening race condition type thing.
yours, Jouni
Ok, it might be the same thing.
I added some debug as Klaus suggested. After restart, vdr instantly deleted a few directories.. So at least it works sometimes. :)
Perhaps the cleanup fails if Plex or another vdr is currently accessing the same files? Maybe vdr then thinks it has deleted them, and does not try again.
17.1.2018 22.28 "Jouni Karvo" jouni.karvo@iki.fi kirjoitti:
Klaus Schmidinger kirjoitti 17.01.2018 klo 11:59:
On 16.01.2018 19:44, Teemu Suikki wrote:
Hi,
I just experienced weird problem. My hard drive became 100% full.
...
This is somehow related to the fact that I now have Plex Media Server
sitting on the VDR recordings directory. But still I could remove the .del directories easily from the command line. After manually deleting them, disk is now only 85% full.. And that's 4TB drive. :) So there were quite a bit of .del directories.
Do you have anything going on that causes frequent "user ineraction" with VDR?
I had a similar problem some time ago (I don't remember how many years, but with vdr 2.2.0). I reported on this mailing list then, but I did not find that email with a short search, now.
My video directory is nfs-mounted to a raspberry pi running another vdr. In my case, I have not changed the configuration in any way, but despite of daily usage, this has not reoccurred. So either some other patch fixed the problem for me, or this is some extremely rarely happening race condition type thing.
yours, Jouni
vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 18.01.2018 08:54, Teemu Suikki wrote:
Ok, it might be the same thing.
I added some debug as Klaus suggested. After restart, vdr instantly deleted a few directories.. So at least it works sometimes. :)
Perhaps the cleanup fails if Plex or another vdr is currently accessing the same files? Maybe vdr then thinks it has deleted them, and does not try again.
In cRemoveDeletedRecordingsThread::Action() VDR tries to get a lock on the video directory. If this fails, it can't remove deleted recordings.
Please add some debug output to this function, to see whether it is called and whether it gets the lock. If it doesn't get the lock while Plex is running, try without Plex.
Klaus
Ok, I did some debugging.
First of all, I noticed something weird that perhaps is not even related to this problem. In vdr.c there is a check:
if ((Now - LastInteract) > ACTIVITYTIMEOUT
if softhhddevice is detached or suspended, "Now - LastInteract" is always zero, and vdr can never enter housekeeping tasks. This must be a bug in softhddevice?
But, with softhddevice attached, housekeeping starts after 60 seconds. However, now with the added debug, I could not reproduce the original problem. :) VDR always deletes my recordings nicely. But now I have the debug enabled, in case it happens again.
2018-01-18 12:26 GMT+02:00 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 18.01.2018 08:54, Teemu Suikki wrote:
Ok, it might be the same thing.
I added some debug as Klaus suggested. After restart, vdr instantly deleted a few directories.. So at least it works sometimes. :)
Perhaps the cleanup fails if Plex or another vdr is currently accessing the same files? Maybe vdr then thinks it has deleted them, and does not try again.
In cRemoveDeletedRecordingsThread::Action() VDR tries to get a lock on the video directory. If this fails, it can't remove deleted recordings.
Please add some debug output to this function, to see whether it is called and whether it gets the lock. If it doesn't get the lock while Plex is running, try without Plex.
Klaus
vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 18.01.2018 21:26, Teemu Suikki wrote:
Ok, I did some debugging.
First of all, I noticed something weird that perhaps is not even related to this problem. In vdr.c there is a check:
if ((Now - LastInteract) > ACTIVITYTIMEOUT
if softhhddevice is detached or suspended, "Now - LastInteract" is always zero, and vdr can never enter housekeeping tasks. This must be a bug in softhddevice?
I guess so.
Klaus
I'm starting to think that maybe my problem IS caused entirely by this softhddevice bug. Because my softhddevice keep freezing quite frequently, I have added a shutdown command that detaches softhddevice and leaves vdr running. And then when I watch something, I'm pressing buttons and using menus and there might be timers recording etc, so vdr never becomes idle enough to do the housekeeping?
I tried to understand the code, but I'm having difficulties. :) in vdr.c, only place that sets LastInteract is this:
Interact = Menu ? Menu : cControl::Control(); // might have been closed in the mean time if (Interact) { LastInteract = Now; eOSState state = Interact->ProcessKey(key); if (state == osUnknown && Interact != cControl::Control()) {
So.. Does this mean that softhddevice's dummy player has menu open all the time? softhddevice.cpp doesn't have really anything menu-related in the dummy player, all those methods must be inherited from main vdr class.
Only thing that looks suspicious is this, dummy player's ProcessKey:
eOSState cSoftHdControl::ProcessKey(eKeys key) { if (SuspendMode == SUSPEND_NORMAL && (!ISMODELESSKEY(key) || key == kMenu || key == kBack || key == kStop)) { delete Player;
Player = NULL; Resume(); SuspendMode = NOT_SUSPENDED; return osEnd; } return osContinue; }
Should it really return osContinue all the time?
2018-01-18 23:37 GMT+02:00 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 18.01.2018 21:26, Teemu Suikki wrote:
Ok, I did some debugging.
First of all, I noticed something weird that perhaps is not even related to this problem. In vdr.c there is a check:
if ((Now - LastInteract) > ACTIVITYTIMEOUT
if softhhddevice is detached or suspended, "Now - LastInteract" is always zero, and vdr can never enter housekeeping tasks. This must be a bug in softhddevice?
I guess so.
Klaus
vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hello,
pe, 2018-01-19 kello 19:48 +0200, Teemu Suikki kirjoitti:
I'm starting to think that maybe my problem IS caused entirely by this softhddevice bug. Because my softhddevice keep freezing quite frequently, I have added a shutdown command that detaches softhddevice and leaves vdr running. And then when I watch something, I'm pressing buttons and using menus and there might be timers recording etc, so vdr never becomes idle enough to do the housekeeping?
I tried to understand the code, but I'm having difficulties. :) in vdr.c, only place that sets LastInteract is this:
Interact = Menu ? Menu : cControl::Control(); // might havebeen closed in the mean time if (Interact) { LastInteract = Now; eOSState state = Interact->ProcessKey(key); if (state == osUnknown && Interact != cControl::Control()) {
So.. Does this mean that softhddevice's dummy player has menu open all the time? softhddevice.cpp doesn't have really anything menu-related in the dummy player, all those methods must be inherited from main vdr class.
Only thing that looks suspicious is this, dummy player's ProcessKey:
eOSState cSoftHdControl::ProcessKey(eKeys key) { if (SuspendMode == SUSPEND_NORMAL && (!ISMODELESSKEY(key) || key == kMenu || key == kBack || key == kStop)) { delete Player;
Player = NULL; Resume(); SuspendMode = NOT_SUSPENDED; return osEnd; } return osContinue;}
Looks like the plugin has some kind of dummy player open. If I remember right, housekeeping tasks are not handled (by design) when you have a player open.
I think I had to work around similar issues when I wrote suspendoutput plugin. It was quite a while ago (2005-09-20: Added vdr idle actions) so I don't remember all the details anymore ...
Anyway, the plugin is relatively simple: http://phivdr.dyndns.org/vdr/vdr-suspendoutput/suspendoutput-2.1.0/susp endoutput.c
Housekeeping tasks are handled in MainThreadHook() and CheckInactivityTimer().
Should it really return osContinue all the time?
2018-01-18 23:37 GMT+02:00 Klaus Schmidinger <Klaus.Schmidinger@tvdr. de>:
On 18.01.2018 21:26, Teemu Suikki wrote:
Ok, I did some debugging.
First of all, I noticed something weird that perhaps is not even related to this problem. In vdr.c there is a check:
if ((Now - LastInteract) > ACTIVITYTIMEOUT
if softhhddevice is detached or suspended, "Now - LastInteract" is always zero, and vdr can never enter housekeeping tasks. This must be a bug in softhddevice?
I guess so.
Klaus
vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 19.01.2018 18:48, Teemu Suikki wrote:
I'm starting to think that maybe my problem IS caused entirely by this softhddevice bug. Because my softhddevice keep freezing quite frequently, I have added a shutdown command that detaches softhddevice and leaves vdr running. And then when I watch something, I'm pressing buttons and using menus and there might be timers recording etc, so vdr never becomes idle enough to do the housekeeping?
I tried to understand the code, but I'm having difficulties. :) in vdr.c, only place that sets LastInteract is this:
Interact = Menu ? Menu : cControl::Control(); // might havebeen closed in the mean time if (Interact) { LastInteract = Now; eOSState state = Interact->ProcessKey(key); if (state == osUnknown && Interact != cControl::Control()) {
So.. Does this mean that softhddevice's dummy player has menu open all the time? softhddevice.cpp doesn't have really anything menu-related in the dummy player, all those methods must be inherited from main vdr class.
Only thing that looks suspicious is this, dummy player's ProcessKey:
eOSState cSoftHdControl::ProcessKey(eKeys key) { if (SuspendMode == SUSPEND_NORMAL && (!ISMODELESSKEY(key) || key == kMenu || key == kBack || key == kStop)) { delete Player;
Player = NULL; Resume(); SuspendMode = NOT_SUSPENDED; return osEnd; } return osContinue;}
Should it really return osContinue all the time?
As long as a cPlayer (or a cReceiver, for that matter) is attached to a cDevice, VDR will not perform its housekeeping tasks. This is to avoid any problems during replay or recording, possibly caused by heavy disk access.
Klaus
2018-01-21 15:46 GMT+02:00 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
As long as a cPlayer (or a cReceiver, for that matter) is attached to a cDevice, VDR will not perform its housekeeping tasks. This is to avoid any problems during replay or recording, possibly caused by heavy disk access.
Ah, I see.. I think softhddevice uses the dummy player to receive keypresses, so it can exit from suspend on demand.
But the full check in vdr.c is this:
if ((Now - LastInteract) > ACTIVITYTIMEOUT && !cRecordControls::Active() && !RecordingsHandler.Active() && !Interface->HasSVDRPConnection() && (Now - cRemote::LastActivity()) > ACTIVITYTIMEOUT) { <start housekeeping>
So, there is a separate check for active recordings, and user activity (cRemote)..
I think I just remove the LastInteract check. I think it is not really useful on my current system anyway. I have a commercial detector running after each recording, and it will run no matter what.. There could be another active recording going, or playback or whatever. VDR housekeeping is a much lighter process.
And currently the check works pretty much the wrong way around.. :) If softhddevice is suspended and vdr left "idle", it will never enter housekeeping because of the check.
My video directory is nfs-mounted to a raspberry pi running another vdr. In my case, I have not changed the configuration in any way, but despite of daily usage, this has not reoccurred. So either some other patch fixed the problem for me, or this is some extremely rarely happening race condition type thing.
Just for reference, my recordings directory is also an nfs share but I don't recall ever experiencing this issue.
-
Jouni Karvo -
Klaus Schmidinger -
Petri Hintukainen -
Teemu Suikki -
VDR User