How to stop a running 'shrink' process that has lost its way?

[YorkshiremanII]

Right

I've been mightily impressed with the improvements to the Queueing functionality, and I have been experimenting with some utilitarian sweeper rules.

The good news is that one of the boxes chewed its way through something like a thousand Q entries without help.
At root level - (Rule- If not decrypted, Q for DC; if not shrunk, Q for Shrink.)
Very impressive results.

Now the question - From a separate set of processing, there is a job running
Started at 22/06/2020 18:08:50
which has now been running for over 2 hours, and survives attempts to hold it, delete it, reboot the box.


There are other items in the Q behind it which I have held of course, so there is just the one ghost job. I've even renamed the source file in the hopes that it would throw an error if unable to access the next block after the reboot.


Two part posting
1) Is there a way to stop a running process in the Q?

2) Suggestion - for any unattended process of course - provide a way of getting a signal to the process to say 'shutdown' or 'kill' -



I'm guessing that sooner or later this process is going to fall over, but I saw the post about a failing decrypt that was running for 3 months, and I'm just
too impatient to wait that long.

 

[MymsMan]

1. Move the recording to a folder that doesn't have auto-shrink enabled (and not covered by your sweeper rule)
2. From a telnet or webshell command line pkill deq

It is very unusual for Shrink to fail so it would be interesting to see any messages from auto.log of by running Shrink on the Opt+ menu

 

[YorkshiremanII]

auto.log seems to have stopped at the inception of processing this recording.

I ran the 'kill deq' command, with seemingly no result. I was able to manually run a shrink - which completed normally in the expected 3 or four minutes. The errant box is currently in another room, being watched by The Management, so I'll leave them to it, and do a restart tomorrow.

At this time of day, processing is suspended. Incidentally, by the time I'd noticed, and tried to stop it, the processing downtime had started. I wonder if there was any interrelated effect - though over the 4 or 5 days the other box was processing 'everything' it seemed to cope happily with the box being up, rebooted, recording, and pretty much life as usual.

More tomorrow - if there is anything to report.

 

[MymsMan]

Speculation:

Have you run out of disk space, both decrypt and shrink leave the originals in the dustbin unless you have turned it off on the settings page.

You can empty the bin by deleting the [Deleted Items] folder or the webif-auto... subfolders but don't do it while recording or playing a recording since mass deletion can cause interference

 

[YorkshiremanII]

Good thought, but no. I'm aware of that feature. In fact, I make use of it. Without space constraints my daughter would fill the box with - well, whatever takes her fancy. The box that ran the 'process everything' filled up, and the Q process dealt with it tidily.

 

[YorkshiremanII]

And the latest is that the process failed 'unable to find .ts file.
The Management had left stuff to record, and that has been correctly dealt with according to the 'auto' rules in place.

So all is well.

and I've had a fascinating excursion further into the wiki and documentation than ever before, in all the years since we bought the first one. Not quite enough to work out how to automate a 'Q for downloading' facility though. If it was able to do that I'd be redundant around the house apart from washing up.

Thanks to everyone..

R