sfatula 185 Posted April 28, 2019 Share Posted April 28, 2019 Since the latest server version, I have Roku Thumbnails looking, well, wrong and awful. It's not possible to explain for me, so, I will link to a video showing the tv and trying to scroll ahead. This is with 4.1.0.26 on Linux as the server. https://www.dropbox.com/s/cu212v680ld6rch/IMG_1166.MOV?dl=0 Obviously I have enabled thumbnail images for the library, every 10 seconds. Is this a known issue? Obviously, the thumbnails are useless. Link to comment Share on other sites More sharing options...
Gilgamesh_48 943 Posted April 28, 2019 Share Posted April 28, 2019 If you have the thumbnails set to store alongside the videos, as I have discovered is best practice, then just delete the current bif file and then run the generate thumbnails task and that "should" clean things up for you. The problem looks to me like the bif file got corrupted during creation. I have seen that happen if the thumbnail creation runs before the file is fully in place. Link to comment Share on other sites More sharing options...
sfatula 185 Posted April 28, 2019 Author Share Posted April 28, 2019 This is true of every thumbnail file since the new version. They are all this way. Link to comment Share on other sites More sharing options...
Gilgamesh_48 943 Posted April 28, 2019 Share Posted April 28, 2019 This is true of every thumbnail file since the new version. They are all this way. Then I have no idea what is wrong. I regenerated all my thumbnails just last week and all 3000+ movies are fine. It looks like you are using recorded TV and I do not use that at all (no reception where I live) so someone other than I will have to come along to help you. I gave it a shot but I am out of my depth. My only thought is that they are generating thumbnails while the recording is happening but I doubt that would be true for every new video. Link to comment Share on other sites More sharing options...
Luke 37048 Posted April 29, 2019 Share Posted April 29, 2019 So this is only for recordings? And no, we don't generate during the recording process. Link to comment Share on other sites More sharing options...
sfatula 185 Posted April 29, 2019 Author Share Posted April 29, 2019 That is correct, 99% of my content, until I migrate stuff from another machine, is TV recordings from Emby dvr. Link to comment Share on other sites More sharing options...
sfatula 185 Posted April 30, 2019 Author Share Posted April 30, 2019 So this is only for recordings? And no, we don't generate during the recording process. So, even if the library has "Enable Real Time Monitoring", it does not generate during the recording process? I am at wits end on this, can't seem to use the Roku skip forward any more since I can't see where I am going. Link to comment Share on other sites More sharing options...
sfatula 185 Posted April 30, 2019 Author Share Posted April 30, 2019 So, generated bif files (a recording had none) via refresh metadata, same results. Played via safari web interface, the thumbnail images were still all messed up. So, it's got to be a server thing. Link to comment Share on other sites More sharing options...
Happy2Play 8273 Posted April 30, 2019 Share Posted April 30, 2019 I would assume dev will need server and possible the corresponding "quick-extract-imageseries" log. But I can only assume this is a specific codec issues as I do not see this in any movie or episode I have. Link to comment Share on other sites More sharing options...
sfatula 185 Posted April 30, 2019 Author Share Posted April 30, 2019 (edited) Sure, no idea where quick-extract log might be. Don't see any. Here's the server log file (attached). It appears (to me) that the thumbnail extraction started around 15:38:01 if I am reading it correctly, tried running one of those commands in a ssh session but it fails, perhaps something else needs to be set for it to work. So, please ignore the following manual attempt if my wild guess means nothing. I just wanted to see what it was doing. On the .1% chance it's relevant.... /opt/emby-server/bin/ffmpeg -ss 00:03:47.972 -f mpegts -i file:"/home/emby/TV/KTEN News at 10/KTEN News at 10 2019_04_29_22_00_00.ts" -an -sn -threads 0 -vframes 1 -vf "scale=600:trunc(ow/a/2)*2,thumbnail=24" -f image2 test.jpg /opt/emby-server/bin/ffmpeg: error while loading shared libraries: libavdevice.so.58: cannot open shared object file: No such file or directory I suppose there could be codec issues, it's just antenna channels via hdhomerun with many different resolutions, etc. Doesn't seem to matter if it's an interlaced or progressive. Worked fine under the Roku thumbnail plugin too. If the bif file is of any use, can upload that too, it's just 4.5MB. I suppose this now belongs in a server forum since it's not roku specific. embyserver.txt Edited April 30, 2019 by sfatula Link to comment Share on other sites More sharing options...
Happy2Play 8273 Posted May 1, 2019 Share Posted May 1, 2019 Pretty sure that is just the episode screen grabber. The thumbnail image process should look like this. 2019-04-29 03:04:32.889 Info MediaEncoder: ProcessRun 'quick-extract-imageseries' Execute: C:\Emby-Server\system\ffmpeg.exe -f mp4 -skip_interval 10 -copyts -i file:"Z:\ServerFolders\Videos\TV Series\Game of Thrones (2011)\Season 8\Game of Thrones.S08E03.The Long Night.mp4" -an -sn -vf "select='eq(pict_type,PICT_TYPE_I)'" -s 320x180 -vsync cfr -r 0.1 -f image2 "C:\Emby-Server\programdata\cache\temp\2e107738b0c54679acf0a112405bd744\img_%05d.jpg" 2019-04-29 03:04:32.894 Info MediaEncoder: ProcessRun 'quick-extract-imageseries' Started. What are your Thumbnail Image settings for that library? Link to comment Share on other sites More sharing options...
sfatula 185 Posted May 1, 2019 Author Share Posted May 1, 2019 (edited) Well, tried several different ones. Currently and the one I started with is all 3 boxes checked under Thumbnail Images, and, every 10 seconds. Tried various combinations, also turned off real time detection didn't seem to matter. Yep, it is the episode grabber and it runs fine anyway since that shows up correctly within Emby. But, running command via built in ffmpeg works too since no library path issue involved. I just wanted to see it. It's really ruined Emby for us. Between ATV numerous issues with the new client, and now even good old reliable Roku acting up, the acceptance factor is diminishing. I hope a dev or someone can help figure out what the actual issue is. Maybe it's a conflict between emby's ffmpeg and ubuntus, i.e., maybe the library path is not searching emby lib first. Edited May 1, 2019 by sfatula Link to comment Share on other sites More sharing options...
CBers 6770 Posted May 1, 2019 Share Posted May 1, 2019 @@sfatula The "quick-extract-imageseries" logs that H2P mentioned, will be in the same logs folder as the server log you posted earlier. Link to comment Share on other sites More sharing options...
sfatula 185 Posted May 1, 2019 Author Share Posted May 1, 2019 Except, they are not: ls -ltotal 21824 -rw-r--r-- 1 emby emby 895147 Apr 27 23:59 embyserver-63692006400.txt -rw-r--r-- 1 emby emby 5326686 Apr 28 23:41 embyserver-63692091763.txt -rw-r--r-- 1 emby emby 38167 Apr 29 00:05 embyserver-63692093139.txt -rw-r--r-- 1 emby emby 5082 Apr 29 00:11 embyserver-63692096272.txt -rw-r--r-- 1 emby emby 46450 Apr 29 01:07 embyserver-63692096940.txt -rw-r--r-- 1 emby emby 1067453 Apr 29 17:22 embyserver-63692155390.txt -rw-r--r-- 1 emby emby 79644 Apr 29 17:24 embyserver-63692155508.txt -rw-r--r-- 1 emby emby 113812 Apr 29 18:57 embyserver-63692161072.txt -rw-r--r-- 1 emby emby 432772 Apr 30 00:00 embyserver-63692179200.txt -rw-r--r-- 1 emby emby 429662 Apr 30 17:36 embyserver-63692242606.txt -rw-r--r-- 1 emby emby 5860174 Apr 30 23:59 embyserver-63692265600.txt -rw-r--r-- 1 emby emby 22493 May 1 02:28 embyserver.txt -rw-r--r-- 1 emby emby 535368 Apr 28 20:52 ffmpeg-directstream-1bbc406f-70c5-4bdf-8d00-97afada4cfa3_1.txt -rw-r--r-- 1 emby emby 543791 Apr 30 22:39 ffmpeg-directstream-81242474-be70-4306-ace4-07039bfefbc1_1.txt -rw-r--r-- 1 emby emby 535533 Apr 30 20:04 ffmpeg-directstream-c6d7f25b-0a57-45a1-9105-d042498f8f35_1.txt -rw-r--r-- 1 emby emby 549905 Apr 28 03:30 ffmpeg-remux-0a23b5b6-f522-40c5-8353-8c71ad47ea02_1.txt -rw-r--r-- 1 emby emby 34592 Apr 29 02:15 ffmpeg-remux-1e5871d7-bec4-4660-b7b5-21ba3b86c7e6_1.txt -rw-r--r-- 1 emby emby 290935 Apr 29 02:16 ffmpeg-remux-30c29729-6c8b-4582-b682-6738ab598e20_1.txt -rw-r--r-- 1 emby emby 282200 Apr 28 16:15 ffmpeg-remux-62307135-7b97-48e7-9787-aacf059e3f8a_1.txt -rw-r--r-- 1 emby emby 351967 Apr 28 03:49 ffmpeg-remux-8d53f468-aeb6-42fd-b145-b838ec94c8c6_1.txt -rw-r--r-- 1 emby emby 171527 Apr 28 16:15 ffmpeg-remux-99a0cd9b-996f-44b2-bc50-9579c57afb2f_1.txt -rw-r--r-- 1 emby emby 326128 Apr 30 17:41 ffmpeg-remux-f00dc3dd-a6b8-4262-b27f-dc9143be0b78_1.txt -rw-r--r-- 1 emby emby 11806 Apr 30 09:19 ffmpeg-transcode-41213772-1dec-4846-9ad1-43b11f3c1719_1.txt -rw-r--r-- 1 emby emby 645889 Apr 28 22:40 ffmpeg-transcode-5b3c391e-80db-40cb-a2d9-8feacb1ae727_1.txt -rw-r--r-- 1 emby emby 16910 Apr 28 22:32 ffmpeg-transcode-63ad3a52-5aae-4edc-82ad-14452a7bca79_1.txt -rw-r--r-- 1 emby emby 1362758 Apr 30 19:05 ffmpeg-transcode-8201f08d-263b-461d-9e57-c3fbc33dbe58_1.txt -rw-r--r-- 1 emby emby 21154 Apr 30 17:42 ffmpeg-transcode-ab4ded72-5283-4671-b57e-fe13ddb3ec56_1.txt -rw-r--r-- 1 emby emby 492719 Apr 30 21:03 ffmpeg-transcode-ce254c9f-a34c-4428-a9ce-c2af275ab4fd_1.txt -rw-r--r-- 1 emby emby 22241 Apr 30 17:59 ffmpeg-transcode-fe074674-1b96-4918-ba0e-0301904aae19_1.txt -rw-r--r-- 1 emby emby 11121 Apr 28 20:21 ffmpeg-transcode-fed88847-4bc5-4156-bdc8-a802317943c9_1.txt -rw-r--r-- 1 emby emby 242949 Apr 28 23:42 hardware_detection-63692091766.txt -rw-r--r-- 1 emby emby 242949 Apr 29 00:57 hardware_detection-63692096274.txt -rw-r--r-- 1 emby emby 242949 Apr 29 01:09 hardware_detection-63692096942.txt -rw-r--r-- 1 emby emby 242949 Apr 29 17:23 hardware_detection-63692155392.txt -rw-r--r-- 1 emby emby 242949 Apr 29 17:25 hardware_detection-63692155510.txt -rw-r--r-- 1 emby emby 242949 Apr 29 18:57 hardware_detection-63692161074.txt -rw-r--r-- 1 emby emby 242948 Apr 30 17:37 hardware_detection-63692242621.txt root@Home-Server:/var/lib/emby/logs# Link to comment Share on other sites More sharing options...
CBers 6770 Posted May 1, 2019 Share Posted May 1, 2019 Except, they are not Not sure what to say then. What happens if you delete a (few) BIF file(s) and run the Scheduled Task? Link to comment Share on other sites More sharing options...
Spaceboy 2493 Posted May 1, 2019 Share Posted May 1, 2019 So this is only for recordings? And no, we don't generate during the recording process.can we please? Link to comment Share on other sites More sharing options...
sfatula 185 Posted May 1, 2019 Author Share Posted May 1, 2019 Not sure what to say then. What happens if you delete a (few) BIF file(s) and run the Scheduled Task? Same results of course. Link to comment Share on other sites More sharing options...
speechles 1917 Posted May 1, 2019 Share Posted May 1, 2019 It obviously isn't pulling keyframes or building complete frames. It is like you are getting B and P frames and seeing them. That green should be the video frame the previous frame blended in. Only the movement of course would be in these frames along with any compression artifacts. So it looks like it is your ffmpeg might not be using the Emby version? That is honestly what it looks like with those messy BIF. Link to comment Share on other sites More sharing options...
sfatula 185 Posted May 1, 2019 Author Share Posted May 1, 2019 (edited) If it wasn't using the emby ffmpeg (due to some sort of packaging error on Embys part), it should work fine as ubuntu ffmpeg works great across many applications I use. Unless, it requires an older version for some reason. Perhaps the bif generator doesn't run with a full path or setup the environment correctly. I agree, it does look like what you describe. It makes me think emby needs a code correction for the thumbnail generator. I think this could be proven easily enough by renaming temporarily the ubuntu ffmpeg, though this wouldn't handle the case where using emby ffmpeg but using non emby ffmpeg libraries. In the log, you can see that the episode grabber does use a full path. Unfortunately, simply renaming /usr/bin/ffmpeg and rerunning the generator produces the exact same file. Strange! If there is any debugging tool, or shell stuff I can do to help figure this out, please let me know. I'd love to make this work somehow. I presume that 2 graphics cards isn't hurting anything... Edited May 1, 2019 by sfatula Link to comment Share on other sites More sharing options...
ebr 14910 Posted May 2, 2019 Share Posted May 2, 2019 @@softworkz Link to comment Share on other sites More sharing options...
softworkz 3335 Posted May 2, 2019 Share Posted May 2, 2019 If it wasn't using the emby ffmpeg (due to some sort of packaging error on Embys part), it should work fine as ubuntu ffmpeg works great across many applications I use. Unless, it requires an older version for some reason. Perhaps the bif generator doesn't run with a full path or setup the environment correctly. I agree, it does look like what you describe. It makes me think emby needs a code correction for the thumbnail generator. I think this could be proven easily enough by renaming temporarily the ubuntu ffmpeg, though this wouldn't handle the case where using emby ffmpeg but using non emby ffmpeg libraries. In the log, you can see that the episode grabber does use a full path. Unfortunately, simply renaming /usr/bin/ffmpeg and rerunning the generator produces the exact same file. Strange! If there is any debugging tool, or shell stuff I can do to help figure this out, please let me know. I'd love to make this work somehow. I presume that 2 graphics cards isn't hurting anything... Emby requires the exact ffmpeg version that it is packaged with. When you say that you have been able to recreate bif files after deleting, then you must also see the extraction logs. Link to comment Share on other sites More sharing options...
sfatula 185 Posted May 2, 2019 Author Share Posted May 2, 2019 (edited) Sure, tell me where they are, they are not in /var/lib/emby/logs like all the usual log files, I provided a log file list a few messages back. I get bif files created every day as I record things every day. I just do not see any log files named like the names requested earlier. The only logs are named: embyserver*.txt ffmpeg-directstream*.txt ffmpeg-remux*.txt ffmpeg-transcode*.txt hardware_detection*.txt Note, all the ffmpeg stuff that I do see logs for works fine, devices play. I just don't see anything for bif files. An artifact of previously having Roku thumbnails plugin installed before the update? I've done a find . -name quick* -print in /var/log, /var/lib/emby, /home/emby, /opt and nothing found. Perhaps a complete emby package removal and install again? What I would not want to lose is my series timers. I can enter everything else. Edited May 2, 2019 by sfatula Link to comment Share on other sites More sharing options...
softworkz 3335 Posted May 2, 2019 Share Posted May 2, 2019 Hmm, I don't have an explanation why that happens. BTW: Do you have correctly configured BIF extraction in your library settings? Where you can choose like "every 10s" ? If no log is showing up, could you please restart Emby server, recreate a bif file and then post the main server log? Link to comment Share on other sites More sharing options...
sfatula 185 Posted May 2, 2019 Author Share Posted May 2, 2019 (edited) I am attaching the settings you asked about. I have restarted emby, and, regenerated a bif. So, have also attached the server log. The program was KTEN News at 10, filename generated is 'KTEN News at 10 2019_05_01_22_00_00-320-10.bif' I did this by rming the file, hitting metadata refresh, and, it generated it again. There is no log file named quick* embyserver.txt Edited May 2, 2019 by sfatula Link to comment Share on other sites More sharing options...
Happy2Play 8273 Posted May 2, 2019 Share Posted May 2, 2019 Interesting, but it was logged. 2019-05-02 18:20:05.787 Info MediaEncoder: ProcessRun 'quick-extract-imageseries' Execute: /opt/emby-server/bin/ffmpeg -f mpegts -skip_interval 10 -copyts -i file:"/home/emby/TV/KTEN News at 10/KTEN News at 10 2019_05_01_22_00_00.ts" -an -sn -s 320x180 -vsync cfr -r 0.1 -f image2 "/var/lib/emby/cache/temp/83cb8fe49f564a2a921931c5bd6bc90c/img_%05d.jpg" I wonder if the additional log is part of debugging? Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now