Why are 4k thumbnails from recorded TV grayed out?

[Happy2Play 8351]

3 minutes ago, MBSki said:

Well that's interesting. @Happy2Play, are your images from the Emby scan or manually? I'll try manual.

Normal import scan.

 

quick-extract-imageseries-8BB488E73EA4_1.txt

[MBSki 1026]

Manually they all look good.

Using the Emby import, not so much.

 

Why would it be different?

[Happy2Play 8351]

Just now, MBSki said:

Manually they all look good.

Using the Emby import, not so much.

 

Why would it be different?

Do they appear that way in all clients?

[MBSki 1026]

Just now, Happy2Play said:

Do they appear that way in all clients?

Yes

[rbjtech 4327]

10 minutes ago, MBSki said:

Manually they all look good.

Using the Emby import, not so much.

 

Why would it be different?

This is really odd. These are not 'solid' grey right - there is 'something' other than grey in those images ?

What I would do is find the exact log for the extract and literally copy it and run as stand alone.

Create the temp folder specified and watch it live when it runs (you'll see all the images get generated)

to add - there is one final step once the images get created, and that is the actual BIF generator - which puts all the images into the BIF file.  But if this works for non-recordings then I'm not sure why this would be an issue - but worth mentioning.

Edited April 6, 2023 by rbjtech

[MBSki 1026]

2 minutes ago, rbjtech said:

This is really odd. These are not 'solid' grey right - there is 'something' other than grey in those images ?

What I would do is find the exact log for the extract and literally copy it and run as stand alone.

Create the temp folder specified and watch it live when it runs (you'll see all the images get generated)

Right, they're gray, but there's an image under the gray.

I'll try the extract command and watch it generate.

[Happy2Play 8351]

Do you get the same results with someone else bif file?

Access Daily With Mario & Kit S13E102-320-10.zip

[MBSki 1026]

18 minutes ago, rbjtech said:

This is really odd. These are not 'solid' grey right - there is 'something' other than grey in those images ?

What I would do is find the exact log for the extract and literally copy it and run as stand alone.

Create the temp folder specified and watch it live when it runs (you'll see all the images get generated)

to add - there is one final step once the images get created, and that is the actual BIF generator - which puts all the images into the BIF file.  But if this works for non-recordings then I'm not sure why this would be an issue - but worth mentioning.

Ok, did that and images look fine that way too. it's the exact same command, so I don't know how the images would be different. Where exactly are the images stored after they're generated? The command shows them going into a temp directory (programdata\cache\temp\788fca7523874661bc3d420b213de4c9\img_%05d.jpg), but where is the final location? The bif file? Can I look at the final images somewhere? I wonder if the Emby client is messing up the image and the image is actually fine.

[MBSki 1026]

4 minutes ago, Happy2Play said:

Do you get the same results with someone else bif file?

Access Daily With Mario & Kit S13E102-320-10.zip 3.68 MB · 0 downloads

Maybe, but I tried one more time using the Emby scan and this time it worked. 

 

I don't know what else to try, but I think i'll enable saving the thumbnails in the media folder and see if that helps going forward. the thumbnails are just that 1 bif file right?

[Happy2Play 8351]

1 minute ago, MBSki said:

the thumbnails are just that 1 bif file right?

Yes all the interval images are repackaged into the bif file.

Do you actal interval images work?

[MBSki 1026]

32 minutes ago, Happy2Play said:

Yes all the interval images are repackaged into the bif file.

Do you actal interval images work?

Ok, I'll save them in the media folder then. 

And yes, they work on all my shows.

[Luke 37236]

7 hours ago, MBSki said:

Ok, did that and images look fine that way too. it's the exact same command, so I don't know how the images would be different. Where exactly are the images stored after they're generated? The command shows them going into a temp directory (programdata\cache\temp\788fca7523874661bc3d420b213de4c9\img_%05d.jpg), but where is the final location? The bif file? Can I look at the final images somewhere? I wonder if the Emby client is messing up the image and the image is actually fine.

How do they look in the temp directory while this is going on?

[rbjtech 4327]

4 hours ago, Luke said:

How do they look in the temp directory while this is going on?

From the results in the thread Luke, the jpg images to construct the bif look to be fine (both via a manual ffmpeg and also via emby) - but they are getting displayed as 'grey' images in the actual emby display.   

[MBSki 1026]

1 hour ago, rbjtech said:

From the results in the thread Luke, the jpg images to construct the bif look to be fine (both via a manual ffmpeg and also via emby) - but they are getting displayed as 'grey' images in the actual emby display.   

What's interesting is that I had to rerun the creation of thumbnails to get it to correctly display. I did record another show yesterday and this time saving images in the media directory. This time, they showed up correctly. No idea why they would be correct when saved in the media directory and wrong when they are not.

[neik 838]

If you're on Ubuntu/Debian reinstalling .29 might help, see over here:

https://emby.media/community/index.php?/topic/117732-wrong-jpeg-library-version-library-is-62-caller-expects-80/&do=findComment&comment=1242313

[MBSki 1026]

@neikI'm in Windows.

[MBSki 1026]

@Luke It seems all my HVEC recordings using the store thumbnails in media folder work. They do NOT work if I don't have that setting checked. Very strange IMO, but at least for me, that appears to be an issue.

Edit: And, this has occurred on 2 computers. Both similar in the sense that the media folder is an HDD and the non-media folder where Emby is located is a fast nvme. Don't know why that would make a difference, but thought I'd mention it.

Edited April 7, 2023 by MBSki

[MBSki 1026]

@Happy2Play@rbjtech Which server version were you using to test? I'm getting the correct images on Beta, but I still can't get it to work on stable.

[rbjtech 4327]

2 hours ago, MBSki said:

@Happy2Play@rbjtech Which server version were you using to test? I'm getting the correct images on Beta, but I still can't get it to work on stable.

I tested your recording on the Latest Beta - .29 - same as you.

[MBSki 1026]

2 minutes ago, rbjtech said:

I tested your recording on the Latest Beta - .29 - same as you.

Maybe the update to ffmpeg 5.1 fixed something, because I can not get it to work in stable.

[rbjtech 4327]

3 minutes ago, MBSki said:

Maybe the update to ffmpeg 5.1 fixed something, because I can not get it to work in stable.

So if you point the manual extraction to use the stable ffmpeg instead - you get the grey images - or no images at all ?  What's the error message if there is one ?

[MBSki 1026]

5 minutes ago, rbjtech said:

So if you point the manual extraction to use the stable ffmpeg instead - you get the grey images - or no images at all ?  What's the error message if there is one ?

Good point. I think I just did manual on beta. I'll try stable a little later.

[MBSki 1026]

I just ran manually on stable, and the images are gray. My guess at the moment is that ffmpeg 5.1 fixed something.

[rbjtech 4327]

18 minutes ago, MBSki said:

I just ran manually on stable, and the images are gray. My guess at the moment is that ffmpeg 5.1 fixed something.

Yep - so I guess either wait for the fix to roll into Stable - or you try simply copying the ffmpeg from Beta replacing the one in Stable - I'd suggest making a copy of it first.

[Happy2Play 8351]

Yep almost all grey frames on that file in 4.7 along with screen capture.