[thumbnails] Package to Auto-Generate Recordings Thumbnails

[af123]

I have noticed that the Webif functionality which extracts audio tracks from recordings to give mp3 files (with mp3 or mp2/ aac audio) does not work with ffmpeg 2.8. It is fine from the command line though so I presume that Webif is calling for a specific ffmpeg version.

What working command line are you using?

 

[MymsMan]

I am not sure whether or not it related to the flag setting or a problem in Flatview but if a thumbnail is created or changed by the package or the manual method (in the recording directory) after the recording has appeared in the [flatview] directory the new thumbnail is not reflected in flatview

 

[Black Hole]

I recall that was discussed when the original thumbnail generator was added to WebIF. Surely the flag must be set properly there?

The relevant topic is here: https://hummy.tv/forum/threads/thumbnails-any-configuration.3241/

The relevant detail is that we decided to distinguish Humax-generated thumbnails from our own thumbnails by adding an extra byte at the end of the file (so they are obvious simply from a file listing / file properties), or possibly by changing the default fourth byte in every four-byte pixel to something other than FF (which means having to read the file). I've not got so far as to find out which.

There was the assumption that the Humax software simply uses the non-existence of a .thm file as a trigger to generate the thumbnail (on play or shutdown), but if it is actually hinging on a flag in the .hmt it is a huge surprise that this has not been spotted by now - our replacement .thms would have been over-written by the standard process, surely somebody would have noticed?

 

[MymsMan]

There was the assumption that the Humax software simply uses the non-existence of a .thm file as a trigger to generate the thumbnail (on play or shutdown), but if it is actually hinging on a flag in the .hmt it is a huge surprise that this has not been spotted by now - our replacement .thms would have been over-written by the standard process, surely somebody would have noticed?

I don't see generated thumbs being overwritten on restart.

 

[MontysEvilTwin]

What working command line are you using?

To extract the main audio track to an mp3 file (128K constant bitrate in this example) the following works:

ffmpeg -i "File 1.ts" -c:a mp3 -b:a 128k "File 1.mp3"

Edit:
The above command does not work with ffmpeg 0.10; you have to specify the encoder. With ffmpeg 2.8 if you specify the output type it selects the best available encoder automatically. The following works with ffmpeg 0.10 and ffmpeg 2.8:

ffmpeg -i "File 1.ts" -c:a libmp3lame -b:a 128k "File 1.mp3"

End of edit.

I presume that when Webif copies the mp2 or aac audio track from a recording with ffmpeg it then renames the resulting file to '.mp3'. To extract mp2 audio is straightforward:

ffmpeg -i "File 1.ts" -c:a copy "File 1.mp2"

Copying an aac audio track is trickier. Copying to an '.aac' file (no container) gives a file which does not play correctly on any of the players I have tried. Copying to an '.m4a' file with ffmpeg fails, even when using a bitstream filter, as it refuses to copy aac_latm into that container. The simplest solution I have found is to copy just the main audio track to a new '.m2ts' file (see below) and then rename this to '.mp3'.

ffmpeg -i "File 1.ts" -map 0:1 -c:a copy "File 1.m2ts"

Here you have to specify the stream you wish to copy or it will copy the video too. As the main audio stream is always at location '0:1', adding '-map 0:1' will work with all the examples in this post.

Edit:
I've figured out what is going on with the aac audio. It is the aac_latm stream format that is the problem with trying to extract to '.aac' without reencoding. It will work if the audio is extracted to a low overhead audio stream file (loas). This works:

ffmpeg -i "File 1.ts" -c:a copy "File 1.loas"

The '.loas' file is then renamed as '.mp3'.
Later versions of ffmpeg (e.g. 2.8) are more fussy than ffmpeg 0.10. The old version will let you copy an mp2 or aac audio stream into a new file with the mp3 extension. The later version does not. The file extension would have to be changed to '.mp3' afterwards.

 

[Black Hole]

I don't see generated thumbs being overwritten on restart.

It wouldn't be on restart, it would be on shutdown. Mine never go through a controlled shutdown.

 

[MymsMan]

It wouldn't be on restart, it would be on shutdown. Mine never go through a controlled shutdown.

I presume the webif reboot is doing a controlled shutdown and I do shutdown with remote

 

[Black Hole]

WebIF reboot is not performing the housekeeping that the standard Humax shutdown process does. You can tell because the reboot happens practically immediately, whereas shutdown takes half a minute (or sometimes more). Going to standby should perform a full shutdown, assuming it is not entering delinquent standby.

 

[MymsMan]

There was the assumption that the Humax software simply uses the non-existence of a .thm file as a trigger to generate the thumbnail (on play or shutdown), but if it is actually hinging on a flag in the .hmt it is a huge surprise that this has not been spotted by now - our replacement .thms would have been over-written by the standard process, surely somebody would have noticed?

I did some testing of this overnight:
I manually deleted thm files from two recordings. One had a thm generated by the new package and one had a thm generated by Humax shut down processing.
I then shut the Humax down using the remote control.
On restart both recordings had the thumbnails re-generated during shut down.
Other recordings with thumbnails generated by the package were untouched.

From this I conclude that the hmt flag is irrelevant for the purposes of regenerating thm files and that it is purely based on whether one exists.

 

[af123]

From this I conclude that the hmt flag is irrelevant for the purposes of regenerating thm files and that it is purely based on whether one exists.

Great, thanks. I had a look at the code and reached the same conclusion (at least as far as I could tell). Good to have proper confirmation.
The next version will set the flag anyway.

The relevant detail is that we decided to distinguish Humax-generated thumbnails from our own thumbnails by adding an extra byte at the end of the file.

Right, the custom thumbnails are one byte longer.

 

[af123]

1.0.4 now available which supports the '-offset xxx' queue flag:

There's also a beta webif update which pulls in ffmpeg 2.8 and has been updated to use that.

 

[Black Hole]

Thumbnail generation seems to be working fine on HDR1 but not on HDR3. I'll look into why this might be later, but in the mean time if anyone has any pointers...

 

[prpr]

if anyone has any pointers...

What does /mod/tmp/auto.log say?

 

[Black Hole]

Well now, thumbnail is working, it's just that in some cases the recording doesn't seem to get queued for thumbnail generation. Unfortunately all the examples are either too old to still be in the auto log, or the one very recent example seems to be in a gap in the log files (auto.log, auto_old.log, or either of the auto<timestamp>.log files)! For some reason there is a gap between auto_old.log and the most recent time stamped file. (The log files quickly reach 2MB because it is in full debug mode.) The task queue shows that the recent example wasn't queued, even for decryption, whereas other recordings around the same time were. I may have uncovered some kind of race condition.

I will have to keep monitoring.

 

[MymsMan]

What happens if you manually Queue for Thumbnail Generation?

I have occasional failures unable to read .ts file if Sweeper or other process has renamed the file before it has been processes but with backup Sweeper rules to queue files that have not been processed by auto decrypt (e.g. detectectads chaserun) it works well for me.

Do you use Flatview? Recordings can appear in Flatview without their icons so I have a sweeper rule especially for flatview.

I rotate logs when they reach 100K and keep 5 generations (advanced settings), I find the smaller logs easier to manage and the date stamps in the file name help locate the correct log quickly

 

[Black Hole]

(Holly's voice) Additional:

The specific recording (in folder [NEWS]) has no .thm listed via WebIF, but is shown as decrypted and ad-detected. However, the task queue does not show it as having been processed for either.

Running the genthumbs diagnostic does not find anything to process (although it says it scanned [NEWS]).

 

[Black Hole]

What happens if you manually Queue for Thumbnail Generation?

I can't see such an option on the OPT+ menu, only "set thumbnail" (the old process).

Do you use Flatview? Recordings can appear in Flatview without their icons so I have a sweeper rule especially for flatview.

Yes, but this specific example is outside Flatview (because of the [-prefix folder).

 

[MymsMan]

but is shown as decrypted and ad-detected.

How was ad detection done? If it was using chaserun mode with cropping then the decryption will be done under the covers and thumbnail detection wont be triggered but you can add a Sweeper rule for that purpose. DetectAds in chaserun mode does not use the Q mechanism other than to create a temporary back up entry while it is running.

I can't see such an option on the OPT+ menu, only "set thumbnail" (the old process).

Select one or more recordings and then the Queue for actions will be enabled at the bottom of the Browse page - much more convenient than OPT+ on each recording.

My sweeper rule

# Thumbnails post detectads
recurse 1 and {!fileexists %basename.thm flag Addetection } action {queue {thumb -offset 5}}

 

[Black Hole]

Aha! So the hypothesis is that all my recordings without thumbnails will have ad detection in common. I'll check.

That doesn't explain why the genthumbs diagnostic didn't queue these for processing now though.

 

[Black Hole]

Should thumbnails be contingent on a recording not having been chase-decrypted? A sweeper rule is a work-around, not a solution.