• 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.

[webif] Web Interface 1.4.x

Status
Not open for further replies.
prpr said:
I have Real-Time-Scheduling enabled so was surprised to see it needed a reboot as all the events had been put in to the Pending queue.
Click to expand...
Quite right, and I have queried this before. The restore process has to perform a "best fit" search because things may have moved around a bit after a retune, so no doubt it takes advantage of processing at boot time.

When I was playing with the supported user's unit recently, I noticed it was doing another (unbidden) reboot after my manually triggered one. Anything to do with tunefix?
 
Black Hole said:
The restore process has to perform a "best fit" search because things may have moved around a bit after a retune
Click to expand...
But it does all that before sticking the entry in the pending queue anyway, so I don't see the relevance.
so no doubt it takes advantage of processing at boot time.
Click to expand...
Don't understand what you are on about here.
When I was playing with the supported user's unit recently, I noticed it was doing another (unbidden) reboot after my manually triggered one. Anything to do with tunefix?
Click to expand...
No. Probably guess at auto-schedule-restore being involved here.
 
Browsing the auto.log, I just found stuff like this:
Code: 
4853    30/06/2018 23:18:52 -   /media/My Video/Films/Who Dares Wins_20180331_1942.ts - Queued for decryption.
4854    30/06/2018 23:29:52 -   /media/My Video/Films/Who Dares Wins_20180331_1942.ts - Queued for decryption.
4855    30/06/2018 23:40:59 -   /media/My Video/Films/Who Dares Wins_20180331_1942.ts - Queued for decryption.
4856    30/06/2018 23:41:02 - De-queuing 11979 - decrypt - /mnt/hd2/My Video/Films/Who Dares Wins_20180331_1942.ts
4857    30/06/2018 23:41:03 -     FAILED - Zero-byte recording, cannot process - 
4858    30/06/2018 23:52:53 -   /media/My Video/Films/Who Dares Wins_20180331_1942.ts - Queued for decryption.
4859    01/07/2018 00:03:52 -   /media/My Video/Films/Who Dares Wins_20180331_1942.ts - Queued for decryption.
4860    01/07/2018 00:14:51 -   /media/My Video/Films/Who Dares Wins_20180331_1942.ts - Queued for decryption.
4861    01/07/2018 00:25:52 -   /media/My Video/Films/Who Dares Wins_20180331_1942.ts - Queued for decryption.
Surely, if it knows the recording is broken, it should remove it, rather than repeatedly trying to do something that can never be achieved?
 
Based on what algorithm? Summarily deleting a "failed" recording leaves no marker in the media list. Flagging it for auto to ignore would just mean scanning for the flag instead of testing for a failed recording - little benefit.

I see no problem periodically retrying, other than it clogging up the log file with repetitive failure reports.
 
What? At 9 times an hour. I'm with prpr on this one. Remove it from the queue and make entry in a log so that you can see what's happened. Pointless keeping on trying.
 
Not quite the same problem prpr found but I posted this in February. My two 'wishes' (a notification and an option to stop processing and put on hold) would highlight any queue problems and give a 'way out'.

peterworks said:
After recording Match of the Day last night it was queued for decryption. On looking this morning at the queue it was still being processed. It failed each time with 'File size mismatch' and, looking at the auto log, it appears to have tried at least 8 times. I have now put it on hold.
I tried the process in this thread:
https://hummy.tv/forum/threads/pict...uto-decrypt-is-running.4169/page-2#post-77050 (post 25 - decrypt issues) but with no success.
I have yet to view the recording so can not ascertain any obvious reason for the mismatch but would it be possible to update the auto/queue facility to put any file that has failed say 3 times on hold ? As there was also no notification, would it be possible create one after the 3 failures ?
One last 'wish' - could there be an option in the queue to stop processing and put on hold ?
Click to expand...
 
Trev said:
What? At 9 times an hour.
Click to expand...
So? It's not like its a lengthy operation.

Okay, suppose it were to delete the source of a failed operation. How long before the first queries come in: "I set xxx to record, but nothing happened"? At least at the moment there is an item in the media list with a lightning bolt thumbnail.
 
I don't think 'we' meant delete it in toto, just flag it so that auto doesn't keep trying to do it's stuff on something that it can't.
 
Black Hole said:
I see no problem periodically retrying, other than it clogging up the log file with repetitive failure reports.
Click to expand...
There is a problem queueing a zero file size recording for decryption because it can never decrypt. OK, if you don't wanna delete it, then just don't bother queueing it in the first place i.e. move the check to somewhere sane rather than where it is now.
It's been doing this every 10 minutes for 3 months. Is that sensible? NO.
 
prpr said:
move the check to somewhere sane rather than where it is now.
Click to expand...
Yes

prpr said:
It's been doing this every 10 minutes for 3 months. Is that sensible? NO.
Click to expand...
So delete the offending file then.

Trev said:
I don't think 'we' meant delete it in toto, just flag it so that auto doesn't keep trying to do it's stuff on something that it can't.
Click to expand...
The auto process would still have to check the flag each time.
 
I honestly don't see what the problem is: "Oh look - there's a load of error messages about something that's hanging up the CF, so I won't bother putting whatever it is right, I'll just ignore it and see if it goes away."

I would have more sympathy if it was something that isn't actually an error, or something the user can't put right.
 
Trev said:
Because if you have 4,850 odd lines of failures, it's a bit difficult to pick out lines that actually convey a useful message amongst that lot. That's the problem as I see it.
Click to expand...
Yes, wood and trees spring to mind. Perhaps I should set fire to it/them. Seems to be the fashionable thing to do.
 
Or remove the offending recording as BH said. Why has it been doing this for three months? I assume that it's because you have not tried to watch it and haven't checked the log for three months?
 
Trev said:
Or remove the offending recording as BH said.
Click to expand...
Obviously that's the first thing I did on discovering it.
Why has it been doing this for three months? I assume that it's because you have not tried to watch it and haven't checked the log for three months?
Click to expand...
True on both counts. But it's not my box.
 
I also have a log file full of failed to decrypt messages. Never seen this before so seeing as how others are seeing this recently perhaps there is something else going on.

And the problem is that it makes the thing very slow to respond to the remote control.
 
Nick95 said:
I also have a log file full of failed to decrypt messages. Never seen this before so seeing as how others are seeing this recently perhaps there is something else going on.

And the problem is that it makes the thing very slow to respond to the remote control.
Click to expand...
Do they all relate to the same programme or different ones?
Is Content sharing on and the DLNA server running?
Most users are decrypting fine, it is unlikely that there is a common fault
 
Status
Not open for further replies.
Back
Top