Jump to content

Recommended Posts

samuelqwe
Posted
4 minutes ago, chef said:

We should probably take the runtime of the file into consideration. The user can set a duration to scan, but we should look at the whole file and add time to the encoding if the episode is more then an hour. It would be safe to speculate that an episode with a runtime of and hour or longer has its intro farther into the stream.

I was thinking we should do a percentage of the episode or something like that. That way, short series only require a few minutes at the start, and longer ones would use more. We just have to make sure it’s the same length between the episodes that are compared together.

  • Agree 1
samuelqwe
Posted
1 hour ago, Micael456 said:

Was reading this one earlier, no mention of high disk io, so possibly this approach works better performance wise? Uses temporary audio files though.

https://jg.sn.sg/chapters/

This seems to be similar to what we were already doing. I believe the high disk utilisation was likely due to how many shows were being processed at once.

  • Like 1
  • Agree 1
rbjtech
Posted
2 minutes ago, samuelqwe said:

This seems to be similar to what we were already doing. I believe the high disk utilisation was likely due to how many shows were being processed at once.

Agreed - that was my initial thoughts as well.  I was testing on an old mechanical HDD and the seek noise was 'horrible' with two parallel streams lol, with a single stream, not only is it silent but much quicker - suggesting the disk seek I/O was the limiting factor here and 'series' processing is probably much more efficient than 'parallel' (in my use case anyway). 

Posted

Hey look at that! There is a database getting populated there 😜

introskipdb.thumb.png.311d569e946d7b0d6699ee33c081de23.png

  • Like 4
samuelqwe
Posted
Just now, rbjtech said:

Agreed - that was my initial thoughts as well.  I was testing on an old mechanical HDD and the seek noise was 'horrible' with two parallel streams lol, with a single stream, not only is it silent but much quicker - suggesting the disk seek I/O was the limiting factor here and 'series' processing is probably much more efficient than 'parallel' (in my use case anyway). 

Especially because the plugin also writes a bunch of temporary files which would add up if you were doing more than one series at a time. It should be a lot better if we can get the fingerprints from FFmpeg directly without saving to a temporary file in the process, but even then this process is more meant as a background task. Once you’ve already processed your library, any additions would scan fairly quickly, even if done one at a time.

  • Agree 1
Posted
49 minutes ago, rbjtech said:

 

45 minutes ago, chef said:

 

@Sammy Did you grab the file a couple posts back on the other page? I fixed the initial compile to work. 

I thought that was just a repost of the previous plugin. Quick work @chef! I'll drop it in now. Thanks! 

  • Like 1
Posted

This is going to take a while. Shouldn't it just scan those episodes missing from when it did work or does it have a new methodology so it has to scan all over again?

 

Screenshot_20210813-111657_Emby.jpg

Posted (edited)

@samuelqwe I've attempted the new ffmpeg cmdline for fingerprinting. However in the emby logs I get:

021-08-13 14:43:48.860 Info Intro Skip: ffmpeg version 4.3.0-emby_2021_02_27-g8f222573e9+634 Copyright (c) 2000-2021 the FFmpeg developers and softworkz for Emby LLC
2021-08-13 14:43:48.861 Info Intro Skip:   built with gcc 9.2.0 (Rev2, Built by MSYS2 project)
2021-08-13 14:43:48.863 Info Intro Skip: Execution Date: 2021-08-13 14:43:48
2021-08-13 14:43:48.881 Info Intro Skip: Unrecognized option 'fp_format'.
2021-08-13 14:43:48.881 Info Intro Skip: Error splitting the argument list: Option not found

 

It seems that it's not understanding 'fp_format'.

Any ideas there? 

 

Here is the args, maybe someone is seeing something I am not:

	    var args = new[]
            {
                $"-t 00:{duration}:00", 
                $"-i \"{input}\"", 
                "-ac 1", 
                "-acodec  pcm_s16le", 
                "-ar 16000",
                "-f chromaprint",
                "-fp_format raw",
                $"\"{output}\""
            };

 

Edited by chef
samuelqwe
Posted
8 minutes ago, chef said:

@samuelqwe I've attempted the new ffmpeg cmdline for fingerprinting. However in the emby logs I get:


021-08-13 14:43:48.860 Info Intro Skip: ffmpeg version 4.3.0-emby_2021_02_27-g8f222573e9+634 Copyright (c) 2000-2021 the FFmpeg developers and softworkz for Emby LLC
2021-08-13 14:43:48.861 Info Intro Skip:   built with gcc 9.2.0 (Rev2, Built by MSYS2 project)
2021-08-13 14:43:48.863 Info Intro Skip: Execution Date: 2021-08-13 14:43:48
2021-08-13 14:43:48.881 Info Intro Skip: Unrecognized option 'fp_format'.
2021-08-13 14:43:48.881 Info Intro Skip: Error splitting the argument list: Option not found
2021-08-13 14:43:48.886 Info Intro Skip: Beginning Chromaprint Extraction: M:\TV\For All Mankind (2019)\Season 1\For All Mankind - 1x02 - He Built the Saturn V.mkv to C:\Users\MediaServer\AppData\Roaming\Emby-Server\programdata\plugins\configurations\introEncoding\140794140843.txt

 

It seems that it's not understanding 'fp_format'.

Any ideas there? 

 

Here is the args, maybe someone is seeing something I am not:


	    var args = new[]
            {
                $"-t 00:{duration}:00", 
                $"-i \"{input}\"", 
                "-ac 1", 
                "-acodec  pcm_s16le", 
                "-ar 16000",
                "-f chromaprint",
                "-fp_format raw",
                $"\"{output}\""
            };

 

Which version of Emby are you using?

My tests last night were with the latest beta’s FFmpeg binary.

Posted
54 minutes ago, samuelqwe said:

Which version of Emby are you using?

My tests last night were with the latest beta’s FFmpeg binary.

Emby 4.6.4.0 - Ffmpeg 4.3.0

I thought it had been added a while ago, maybe the chromaprint is left out of stable release?

What ffmpeg release do you have?

 

 

Posted
1 hour ago, chef said:

Hey look at that! There is a database getting populated there 😜

introskipdb.thumb.png.311d569e946d7b0d6699ee33c081de23.png

I got nuthin!

samuelqwe
Posted
3 minutes ago, chef said:

Emby 4.6.4.0 - Ffmpeg 4.3.0

I thought it had been added a while ago, maybe the chromaprint is left out of stable release?

What ffmpeg release do you have?

 

 

I thought so too, but maybe it was left out of the stable. I’ll see if I can check when I get home in a few hours.

Posted
17 minutes ago, Sammy said:

I got nuthin!

Oh, you wouldn't see a database yet in that release. It'll be added in something new.

Posted

@ebr any idea why the stable release of emby wouldn't know some of the command lines for ffmpeg, but the beta would?

Posted
3 hours ago, Sammy said:

This is going to take a while. Shouldn't it just scan those episodes missing from when it did work or does it have a new methodology so it has to scan all over again?

 

Screenshot_20210813-111657_Emby.jpg

@Sammy sorry I missed this post earlier. It should skip episode that have recorded data for title sequences. But, because it is looking at the file system, it takes a really long time to process. It isn't great.

The database tables I have recently written should speed things up considerably faster.

Just have to figure out this ffmpeg issue, and I can continue writing the database. 

samuelqwe
Posted
3 hours ago, chef said:

@ebr any idea why the stable release of emby wouldn't know some of the command lines for ffmpeg, but the beta would?

Just had a chance to take a look at this, and the stable version does include chromaprint. I was even able to test it and it worked no problem with this command: 

ffmpeg -t 300 -i /mnt/user/media/TV\ Shows/Brooklyn\ Nine-Nine/Season\ 7/Brooklyn\ Nine-Nine\ \(2013\)\ -\ S07E01\ -\ Manhunter\ -\ \[EAC3\ 5.1\].mkv -ac 1 -acodec pcm_s16le -ar 16000 -c:v nul -f chromaprint -fp_format raw /mnt/user/media/fingerprint.bin

The path being between quotes or using escape characters like I did shouldn't matter, but perhaps that had something to do with it.

  • Thanks 1
Posted
46 minutes ago, chef said:

@Sammy sorry I missed this post earlier. It should skip episode that have recorded data for title sequences. But, because it is looking at the file system, it takes a really long time to process. It isn't great.

The database tables I have recently written should speed things up considerably faster.

Just have to figure out this ffmpeg issue, and I can continue writing the database. 

All done..

image.thumb.png.03a0b65d2b9c76e2739aa2b14caca4f4.png

samuelqwe
Posted
11 minutes ago, Sammy said:

Is something missing??

image.thumb.png.641db96b644a29aa0821c95de4adcd30.png

Did you run the detect title sequence task after the fingerprinting was done?

samuelqwe
Posted

@chef Btw, I believe I was wrong in my post yesterday about no longer requiring hamming distances. I hadn't done thorough testing so I wasn't 100% sure that I was reading the binary data correctly, but it turns out that each int in our fingerprint arrays is actually 4 bytes of that .bin file. If I do that, then the numbers line up with what we had before and hamming distances are still needed for the correct result. It still seemed to be working when I was reading a single byte, but that may or may not have been a fluke.

Also, I edited the original post on this to correct the information.

  • Thanks 1
Posted (edited)
30 minutes ago, samuelqwe said:

Did you run the detect title sequence task after the fingerprinting was done?

I believe so I did not.. This is the exact sequence which is exactly opposite..

image.thumb.png.03a0b65d2b9c76e2739aa2b14caca4f4.png

Edited by Sammy
samuelqwe
Posted
1 minute ago, Sammy said:

I believe so.. This is the exact sequence:

image.thumb.png.03a0b65d2b9c76e2739aa2b14caca4f4.png

Those tasks are in the wrong order, so Episode Audio Fingerprinting needs to be run before Detect Episode Title Sequence.

In your screenshot, it looks like you didn’t run the Detect Episode Title Sequence task after the fingerprinting process.

  • Agree 1
Posted (edited)

It looks like my version of ffmpeg doesn't have the right stuff. Weird! I tried the command prompt and the error is still happening for me.

 

EDIT: after installing emby on another machine and checking ffmpeg, the fp_format error still exists. I wonder if it's a windows version thing.

 

 

Edited by chef
samuelqwe
Posted
23 minutes ago, chef said:

It looks like my version of ffmpeg doesn't have the right stuff. Weird! I tried the command prompt and the error is still happening for me.

 

EDIT: after installing emby on another machine and checking ffmpeg, the fp_format error still exists. I wonder if it's a windows version thing.

 

 

Strange, I would expect FFmpeg to be pretty similar on all platforms, but then again I use unRAID/Docker so that would certainly be plausible.

Maybe check with "ffmpeg -formats" to see if you do actually have chromaprint in your build of FFmpeg

  • Like 1
Happy2Play
Posted

Does not look like it is enabled in Emby ffmpeg (at least in Windows) in ffmpeg 4.3 or 4.4.

Emby vs downloaded ffmpeg

image.thumb.png.a99e8c23cd38aff3428dccfccddd184c.png

  • Sad 1
Guest
This topic is now closed to further replies.
×
×
  • Create New...