Queue processing oddity

A download yesterday produced odd results I hadn't seen before. The program was part of a series in a folder marked for auto-mpg. The log extract below shows successful decrypt, failed detectads, and two mpg output files. Apologies for the poor formatting.

Code:
Queued Tasks
Queued Tasks
13443    20/05/2024 00:22:40    The Piano/The Piano_20240519_2100    mpg     COMPLETE    00:05:17    1.3 GiB in 317.115 seconds - 4.18 MiB/s    20/05/2024 00:43:05
13442    20/05/2024 00:22:39    Singles/Women's Cricket_ England v____20240519_2315    decrypt     COMPLETE    00:02:51    810.17 MiB in 170.394 seconds - 4.75 MiB/s    20/05/2024 00:37:46
13441    20/05/2024 00:21:45    Football/Match of the Day_20240519_2230    decrypt     COMPLETE    00:12:51    3.88 GiB in 770.667 seconds - 5.16 MiB/s    20/05/2024 00:34:55
13440    19/05/2024 22:05:46    The Piano/New_ The Piano_20240519_2100    detectads     FAILED        Could not load .ts file    20/05/2024 00:43:05
13439    19/05/2024 22:01:38    Singles/John Betjeman_ The Last Laugh -____20240519_1955    decrypt     COMPLETE    00:05:34    1.73 GiB in 333.3 seconds - 5.32 MiB/s    19/05/2024 22:11:20
13438    19/05/2024 22:00:48    The Piano/New_ The Piano_20240519_2100    mpg     COMPLETE    00:05:22    1.3 GiB in 321.507 seconds - 4.13 MiB/s    19/05/2024 22:16:43
13437    19/05/2024 22:00:48    The Piano/New_ The Piano_20240519_2100    decrypt     COMPLETE    00:04:43    1.3 GiB in 281.81 seconds - 4.71 MiB/s    19/05/2024 22:05:45
 
I suggest newk got to the .ts while it was still pending for detectads, therefore detectads couldn't find the (renamed) .ts. I think you now have two versions of the .mpg, one made before the newk rename and the other made after.
 
What's the question?
The failed detectads is presumably due to the New prefix being removed after it's been queued but before it's been processed.
 
I suggest newk got to the .ts while it was still pending for detectads, therefore detectads couldn't find the (renamed) .ts. I think you now have two versions of the .mpg, one made before the newk rename and the other made after.
Your diagnosis confirms my less well-informed guesses. But I watch almost nothing other than the news live, and so have made a huge number of recordings in the years I've used the customised firmware. I've never seen anything like this before and was curious as to why it happened. I rather assumed that the software organises an orderly queue of the various processes, but I guess that was overly optimistic given the nature of the beast.
 
I presume these exact circumstances have simply never occurred before, or if they did you didn't notice. Having a duplicated .mpg is a smoking gun.

I think newk predates implementation of a process queue, so then it becomes a free-for-all. It might be possible to use sweeper rules to ensure no other processes trigger until newk has had its bite (or vice versa). Or just don't use newk, and (if you must) use sweeper rules to replicate it (I believe there are library rules which can do that). Certainly it would be safest to delay any renaming until other processing is complete.

If that's too much trouble, put up with the occasional glitch.
 
Last edited:
[...]

If that's too much trouble, put up with the occasional glitch.
The Humax's quirks, even without the cfw, have long enured me to glitches. I can't program my way out of a paper bag, but I've been beta testing software since CP/M days and have become used to report such oddities.
 
I've never seen anything like this before and was curious as to why it happened.
it might be in the auto.log file.
I think newk predates implementation of a process queue, so then it becomes a free-for-all.
newk doesn't rename things post-record. It modifies the schedule pre-record, and only at boot time, to remove prefixes from Series recording folders.
has had it's bite
Ahem.
Or just don't use newk, and (if you must) use sweeper rules to replicate it
I believe that's how it's already being done, but it would be nice to see the actual rules in use.
 
Back
Top