everthewatcher
Forum Supporter
Got an item stuck 'RUNNING' in queued tasks after a crash while auto-decrypting. Can someone remind me how to clear it as none of the buttons work on it?
-
The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm
There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.
Item stuck in Queue Tasks after crash - how to remove reminder please
- Thread starter everthewatcher
- Start date
Black Hole
May contain traces of nut
Delete the queue:
rm /mod/etc/queue.db
OP
everthewatcher
Forum Supporter
Thank you. This time I'll stick it in the Humax Notes file.
Last edited:
OP
everthewatcher
Forum Supporter
It would be nice but here it happens very infrequently hence my asking for a reminder. Other than shrinking three files there's nothing else in the queue.
FWIW the last crash was back in October with no consequences, then twice yesterday after installing the IR package for a play. It was too much of a coincidence so I've removed it to see what happens.
alanofcleeves
Active Member
When I have had this problem I have used the Webif to rename the recording that is stuck in the queue. The process then will report 'file not found' and move on as normal.
OP
everthewatcher
Forum Supporter
Tried that tactic but got a 'file in use' refusal.
alanofcleeves
Active Member
I think if you disallow auto processes for a bit you can then do whatever you want with the file.
MymsMan
Ad detector
It is perfectly normal for a queued task to be back in Running after a crash - it is supposed to rerun incomplete queued tasks.
What would be abnormal is when a task stays in running for an unusually long time (irrespective of whether the a crash had occurred) and needs to be investigated by looking at auto.log - how long after restart did you try to kill it (the queue display shows the started time)
Just deleting the queue entry or entire queue could result in being added back on to the queue by the autodecrypt flag setting. It would be better to put the entry into HOLD status
What would be abnormal is when a task stays in running for an unusually long time (irrespective of whether the a crash had occurred) and needs to be investigated by looking at auto.log - how long after restart did you try to kill it (the queue display shows the started time)
Just deleting the queue entry or entire queue could result in being added back on to the queue by the autodecrypt flag setting. It would be better to put the entry into HOLD status
OP
everthewatcher
Forum Supporter
Tried deleting and HOLD. Had no effect.
Black Hole
May contain traces of nut
The only things which will not get reinstated is any task which has been added to the queue manually. Jobs which are the result of auto-processing will just get re-added.
Or a glitch (such as a corrupted queue.db file) just needs sorting out and everything will be fine after that.
prpr
Well-Known Member
Yes, but is it really running, or does it just say it is (because that's what was set before the crash) and it really isn't?
MymsMan
Ad detector
The 'file in use' would indicate that it probably is running - it could be something else but unless the recording was being played it is fairly unlikely to be in use by anything else.
Restarting after failure is pretty well tested over the years
OP
everthewatcher
Forum Supporter
I gave it more than long enough to finish once it once I'd restarted the machine, say from around 9am until well after BH's post at 11:32am. The Queue is set to run from 23:00 and the machine set to switch off at midnight but was still on and unresponsive so it was obvious it had crashed.
Can't remember now if the 'file in use' came from the WebIF or Windows on the machine I used to copy off the files belonging to the stuck item. Once I'd deleted the Queue DB I copied them back and manually decrypted the item with no problem.