Jump to content


Photo

4.2.0.1 Beta - Roku Thumbnail images not being created.

centos Roku linux thumbnail

Best Answer Karpana , 23 May 2019 - 07:31 AM

@Luke & @Happy2Play

I have some fortuitous news to report.
It seems I've gotten this to work, though for the life of me, I can't explain why this solution was necessary.

Yesterday, on a whim, I disabled the "save thumbnails to media folder" option on one of my libraries and forced the TV episode in question to update missing metadata.
The .bif file was successfully created in the /emby/metadata folder.

I re-enabled the option to save thumbnails to media folder (and deleted the bif file in metadata) and it again failed.

the only "real" difference between the /metadata folder area and my media folder is who owned the folder. 

Keeping in mind that my media folder is mounted from my NAS, I recognized I have some control about which owner/group (on the CentOS side) the NAS is mounted as.

I went into my /etc/fstab file, changed the uid&gid from 5000/6000 (which was working through emby 4.1.0.23) and works for all everything but .bif files and changed it to 997/994 (emby's user and group).
I unmounted the NAS from CentOS and remounted it.

I then forced emby to update missing metadata, and much to my surprise, it worked!

As indicated, I can't explain why this worked, but it has.

I have a bit more testing, specifically around the creation of other files and functionality validation.  But for the time being this is a fortuittous start.


This is what my directory structure permissions look like now (note the 5000/6000 is now showing emby/emby)
I guess with this change, assuming everything else checks out, I should be able to reduce permissions *away* from 777.

I'll send an update in the next few days to let you know how everything else is holding up.

/
	drwxr-xr-x.   3 root root     17 Jan 25 19:11 mnt
	dr-xr-xr-x.  17 root root    242 Apr 29 20:03 ..
	dr-xr-xr-x.  17 root root    242 Apr 29 20:03 .

/mnt
	drwxr-xr-x.  3 root root  17 Jan 25 19:11 .
	drwxr-xr-x.  3 root root  21 Jan 25 19:11 nas
	dr-xr-xr-x. 17 root root 242 Apr 29 20:03 ..

/mnt/nas
	drwxr-xr-x. 3 root root 17 Jan 25 19:11 ..
	drwxr-xr-x. 3 root root 21 Jan 25 19:11 .
	drwxr-xr-x. 3 root root 20 Jan 25 19:13 lithium

/mnt/nas/lithium
	drwxr-xr-x. 3 root root   21 Jan 25 19:11 ..
	drwxr-xr-x. 3 root root   20 Jan 25 19:13 .
	drwxrwxrwx. 2 emby emby 8192 May 20 14:55 videos

/mnt/nas/lithium/videos
	drwxr-xr-x. 3 root root       20 Jan 25 19:13 ..
	drwxrwxrwx. 2 emby emby        0 May 16 22:59 TV Shows
	drwxrwxrwx. 2 emby emby     8192 May 20 14:55 .

/mnt/nas/lithium/videos/TV Shows
	drwxrwxrwx. 2 emby emby 40960 May 16 22:59 .
	drwxrwxrwx. 2 emby emby  8192 May 20 14:55 ..
	drwxrwxrwx. 2 emby emby     0 Apr 23 17:55 Star Trek - Discovery

/mnt/nas/lithium/videos/TV Shows/Star Trek - Discovery
	drwxrwxrwx. 2 emby emby   4096 Apr 23 17:55 .
	drwxrwxrwx. 2 emby emby  40960 May 16 22:59 ..
	drwxrwxrwx. 2 emby emby      0 May 20 14:43 Season 02

/mnt/nas/lithium/videos/TV Shows/Star Trek - Discovery/Season 02
	drwxrwxrwx. 2 emby emby       4096 Apr 23 17:55 ..
	drwxrwxrwx. 2 emby emby      24576 May 20 14:43 .
Go to the full post


  • Please log in to reply
42 replies to this topic

#21 Karpana OFFLINE  

Karpana

    Advanced Member

  • Members
  • 77 posts
  • Local time: 10:33 AM

Posted 06 May 2019 - 08:36 PM

Wanting to report that this issue is still occuring on Beta 4.2.0.4

Continuing to evaluate and investigate the permissions problem that @Luke was referring to, and with everything set to permission to everyone and everything, this problem is still occuring.

Attached File  sshot.jpg   191.08KB   1 downloads

 

I continue to assert that this must be a code problem that was introduced on/after v4.1.0.23

 

What additional information do you require to debug/resolve this issue?



#22 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 137605 posts
  • Local time: 11:33 AM

Posted 07 May 2019 - 02:26 PM

I'm not sure what the answer is yet for your environment.

#23 Karpana OFFLINE  

Karpana

    Advanced Member

  • Members
  • 77 posts
  • Local time: 10:33 AM

Posted 07 May 2019 - 02:45 PM

Fair.
Thank you for the update.

Let me know if there's anything you need from me.



I still find it confusing that the "final" .bif file seems to be built in the target directory and then subsequently deleted.
I'll rerun that test tonight to confirm my findings.

 



#24 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 137605 posts
  • Local time: 11:33 AM

Posted 14 May 2019 - 01:06 AM

Can you try creating a small video library on the same drive the server is installed on? Please see how that compares. thanks.



#25 Karpana OFFLINE  

Karpana

    Advanced Member

  • Members
  • 77 posts
  • Local time: 10:33 AM

Posted 14 May 2019 - 06:50 PM

Hey @Luke

Just noticed your message now, after upgrading to 4.2.0.5 BETA.
and doing one more test.

I can assuredly confirm that for some reason, although the individual jpgs are being extracted into /var/lib/emby/cache/temp, it does appear that the .bif file is physically built within the target directory, and then promptly removed/deleted.

As for the test you asked for, I did the following

1) created a new directory on my NAS  (via windows file sharing)
2) create a library in Emby title TestMedia (via chrome).  I used my existing movies folder as a template for the settings.
3) took one of my recently obtained videos and in a directory on my machine
==> created a directory Escape Room (2019)
==> moved the .mp4 file into the folder and named it Escape Room (2019) [Bluray-720p].mp4

4) moved the directory from my PC to my NAS (via windows file sharing)

5) started a tail on the emby log file (at the linux level)

6) went to emby => Gear => Library and located my TestMedia library => clicked the 3 dots => Scan Library => Scan Library for new and updated files

7) watched the log and found the dreaded error (see log snippet below)

8) went to the NAS file share (via windows file sharing) and noticed that Emby successfully wrote everything, except for the.bif file 

 

Attached File  sshot.jpg   48.76KB   1 downloads

2019-05-14 17:35:16.842 Info HttpServer: HTTP GET http://helium:8096/emby/Library/VirtualFolders. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36
2019-05-14 17:35:16.846 Info HttpServer: HTTP Response 200 to 192.168.22.15. Time: 4ms. http://helium:8096/emby/Library/VirtualFolders
2019-05-14 17:35:16.869 Info HttpServer: HTTP GET http://helium:8096/emby/Localization/cultures. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36
2019-05-14 17:35:16.870 Info HttpServer: HTTP GET http://helium:8096/emby/Localization/countries. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36
2019-05-14 17:35:16.872 Info HttpServer: HTTP Response 200 to 192.168.22.15. Time: 2ms. http://helium:8096/emby/Localization/countries
2019-05-14 17:35:16.872 Info HttpServer: HTTP Response 200 to 192.168.22.15. Time: 3ms. http://helium:8096/emby/Localization/cultures
2019-05-14 17:35:16.908 Info HttpServer: HTTP GET http://helium:8096/emby/Libraries/AvailableOptions?LibraryContentType=movies&IsNewLibrary=false. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36
2019-05-14 17:35:16.914 Info HttpServer: HTTP Response 200 to 192.168.22.15. Time: 6ms. http://helium:8096/emby/Libraries/AvailableOptions?LibraryContentType=movies&IsNewLibrary=false
2019-05-14 17:35:18.399 Info HttpServer: HTTP POST http://helium:8096/emby/Library/VirtualFolders/LibraryOptions. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36
2019-05-14 17:35:18.403 Info HttpServer: HTTP Response 204 to 192.168.22.15. Time: 4ms. http://helium:8096/emby/Library/VirtualFolders/LibraryOptions
2019-05-14 17:35:18.524 Info HttpServer: HTTP GET http://helium:8096/emby/Library/VirtualFolders. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36
2019-05-14 17:35:18.527 Info HttpServer: HTTP Response 200 to 192.168.22.15. Time: 3ms. http://helium:8096/emby/Library/VirtualFolders
2019-05-14 17:35:25.371 Info HttpServer: HTTP POST http://helium:8096/emby/Items/83c0876f4b2039ca93d6129a4c13715f/Refresh?Recursive=true&ImageRefreshMode=Default&MetadataRefreshMode=Default&ReplaceAllImages=false&ReplaceAllMetadata=false. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36
2019-05-14 17:35:25.372 Info HttpServer: HTTP Response 204 to 192.168.22.15. Time: 1ms. http://helium:8096/emby/Items/83c0876f4b2039ca93d6129a4c13715f/Refresh?Recursive=true&ImageRefreshMode=Default&MetadataRefreshMode=Default&ReplaceAllImages=false&ReplaceAllMetadata=false
2019-05-14 17:35:25.498 Debug MediaEncoder: Ffprobe -i file:"/mnt/nas/lithium/videos/TestMedia/Escape Room (2019)/Escape Room (2019) [Bluray-720p].mp4" -threads 0 -v info -print_format json -show_streams -show_chapters -show_format -show_data
2019-05-14 17:35:25.498 Info MediaEncoder: ProcessRun 'ffprobe' Execute: /opt/emby-server/bin/ffprobe -i file:"/mnt/nas/lithium/videos/TestMedia/Escape Room (2019)/Escape Room (2019) [Bluray-720p].mp4" -threads 0 -v info -print_format json -show_streams -show_chapters -show_format -show_data
2019-05-14 17:35:25.514 Info MediaEncoder: ProcessRun 'ffprobe' Started.
2019-05-14 17:35:25.718 Info MediaEncoder: ProcessRun 'ffprobe' Process exited with code 0
2019-05-14 17:35:26.028 Info HttpClient: POST https://vip-api.opensubtitles.org/xml-rpc
2019-05-14 17:35:27.289 Info HttpClient: POST https://vip-api.opensubtitles.org/xml-rpc
2019-05-14 17:35:27.955 Info HttpClient: POST https://vip-api.opensubtitles.org/xml-rpc
2019-05-14 17:35:28.546 Info SubtitleManager: Saving subtitles to /mnt/nas/lithium/videos/TestMedia/Escape Room (2019)/Escape Room (2019) [Bluray-720p].en.srt
2019-05-14 17:35:28.561 Info MediaEncoder: ProcessRun 'quick-extract-imageseries' Execute: /opt/emby-server/bin/ffmpeg -f mp4 -skip_interval 10 -copyts -i file:"/mnt/nas/lithium/videos/TestMedia/Escape Room (2019)/Escape Room (2019) [Bluray-720p].mp4" -an -sn -vf "select='eq(pict_type,PICT_TYPE_I)'" -s 320x133 -vsync cfr -r 0.1 -f image2 "/var/lib/emby/cache/temp/9da0d28fba39462b89f5039d403d5e98/img_%05d.jpg"
2019-05-14 17:35:28.574 Info MediaEncoder: ProcessRun 'quick-extract-imageseries' Started.
2019-05-14 17:35:41.715 Info MediaEncoder: ProcessRun 'quick-extract-imageseries' Process exited with code 0
2019-05-14 17:35:41.864 Error App: Error creating thumbnails for /mnt/nas/lithium/videos/TestMedia/Escape Room (2019)/Escape Room (2019) [Bluray-720p].mp4
        *** Error Report ***
        Version: 4.2.0.5
        Command line: /opt/emby-server/system/EmbyServer.dll -programdata /var/lib/emby -ffdetect /opt/emby-server/bin/ffdetect -ffmpeg /opt/emby-server/bin/ffmpeg -ffprobe /opt/emby-server/bin/ffprobe -restartexitcode 3 -updatepackage emby-server-rpm_{version}_x86_64.rpm
        Operating system: Unix 3.10.0.957
        64-Bit OS: True
        64-Bit Process: True
        User Interactive: True
        Runtime: file:///opt/emby-server/system/System.Private.CoreLib.dll
        Processor count: 4
        Program data path: /var/lib/emby
        Application directory: /opt/emby-server/system
        System.UnauthorizedAccessException: System.UnauthorizedAccessException: Access to the path is denied. ---> System.IO.IOException: Operation not permitted
           --- End of inner exception stack trace ---
           at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter)
           at Interop.CheckIo(Int64 result, String path, Boolean isDirectory, Func`2 errorRewriter)
           at System.IO.FileSystem.CopyFile(String sourceFullPath, String destFullPath, Boolean overwrite)
           at System.IO.File.Copy(String sourceFileName, String destFileName, Boolean overwrite)
           at Emby.Server.Implementations.IO.ManagedFileSystem.CopyFile(String source, String target, Boolean overwrite)
           at MediaBrowser.Providers.MediaInfo.ThumbnailGenerator.CreateThumbnailSet(Video item, LibraryOptions libraryOptions, Int32 width, CancellationToken cancellationToken)
           at MediaBrowser.Providers.MediaInfo.ThumbnailGenerator.CreateThumbnailSets(Video item, LibraryOptions libraryOptions, CancellationToken cancellationToken)
           at MediaBrowser.Providers.MediaInfo.ThumbnailGenerator.RefreshThumbnailImages(Video item, LibraryOptions libraryOptions, IDirectoryService directoryService, List`1 chapters, Boolean extractImages, Boolean saveChapters, CancellationToken cancellationToken)
        Source: System.IO.FileSystem
        TargetSite: Void ThrowExceptionForIoErrno(ErrorInfo, System.String, Boolean, System.Func`2[Interop+ErrorInfo,Interop+ErrorInfo])
        InnerException: System.IO.IOException: Operation not permitted
        Source:
        TargetSite:

2019-05-14 17:35:41.894 Info HttpClient: GET https://api.themoviedb.org/3/configuration?api_key=f6bd687ffa63cd282b6ff2c6877f2669
2019-05-14 17:35:42.236 Info App: MovieDbProvider: Finding id for item: Escape Room
2019-05-14 17:35:42.243 Info HttpClient: GET https://api.themoviedb.org/3/search/movie?api_key=f6bd687ffa63cd282b6ff2c6877f2669&query=Escape+Room&language=en
2019-05-14 17:35:42.544 Info HttpClient: GET https://api.themoviedb.org/3/movie/522681?api_key=f6bd687ffa63cd282b6ff2c6877f2669&append_to_response=casts,releases,images,keywords,trailers&language=en&include_image_language=en,null
2019-05-14 17:35:42.880 Info HttpClient: GET https://private.omdbapi.com?apikey=fe53f97e&i=tt5886046&plot=short&tomatoes=true&r=json
2019-05-14 17:35:43.154 Info HttpClient: GET https://api.themoviedb.org/3/movie/522681?api_key=f6bd687ffa63cd282b6ff2c6877f2669&append_to_response=casts,releases,images,keywords,trailers
2019-05-14 17:35:43.268 Info HttpClient: GET https://image.tmdb.org/t/p/original/15AlGTlaZa3W2zmIL4ehnCh8Xe0.jpg
2019-05-14 17:35:43.527 Info HttpClient: GET https://image.tmdb.org/t/p/original/mWLljCmpqlcYQh7uh51BBMwCZwN.jpg
2019-05-14 17:35:43.732 Info HttpClient: GET https://webservice.fanart.tv/v3/movies/522681?api_key=5c6b04c68e904cfed1e6cbc9a9e683d4
2019-05-14 17:35:44.337 Info HttpClient: GET https://assets.fanart.tv/fanart/movies/522681/hdmovielogo/escape-room-5c5b1227e2718.png
2019-05-14 17:35:45.378 Info HttpClient: GET https://assets.fanart.tv/fanart/movies/522681/moviethumb/escape-room-5c530dbd058a6.jpg



#26 Karpana OFFLINE  

Karpana

    Advanced Member

  • Members
  • 77 posts
  • Local time: 10:33 AM

Posted 14 May 2019 - 06:51 PM

Is the location of where the .bif file is supposed to get assembled from the .jpg files something that is configurable?
I'm wondering if that's something worth peeking at.

Also...is the source code related to the.bif file creation something that a member of the public can peek at?
I'm a developer by training, and have been in the development industry for 20+ years.



#27 Karpana OFFLINE  

Karpana

    Advanced Member

  • Members
  • 77 posts
  • Local time: 10:33 AM

Posted 14 May 2019 - 07:05 PM

I figured I would try one more time to "refresh the metadata" but with inotify turned on.

 

screen shot is attached.
Itclearly shows that the .bif file is being "assembled' in the target directory,closed and then deleted.

 

Attached File  inotify.png   12.1KB   1 downloads



#28 Happy2Play OFFLINE  

Happy2Play

    Trial and Error

  • Moderators
  • 15626 posts
  • Local time: 08:33 AM
  • LocationWashington State

Posted 14 May 2019 - 09:19 PM

To me there is still a permission issue, but it is odd it only affect bif files though.

2019-05-14 17:35:41.864 Error App: Error creating thumbnails for /mnt/nas/lithium/videos/TestMedia/Escape Room (2019)/Escape Room (2019) [Bluray-720p].mp4

System.UnauthorizedAccessException: System.UnauthorizedAccessException: Access to the path is denied. ---> System.IO.IOException: Operation not permitted


Edited by Happy2Play, 14 May 2019 - 09:22 PM.


#29 Karpana OFFLINE  

Karpana

    Advanced Member

  • Members
  • 77 posts
  • Local time: 10:33 AM

Posted 14 May 2019 - 09:34 PM

I completely agree.
And thats why I've been using various monitors, namely inotify and a custom written high speed Unix directory scanner.

I can actually see the file in the target directory it then disappears about the same time the log shows the error.

This is why I'm trying to find out why emby is deleting the file it created.

Edited by Karpana, 14 May 2019 - 09:35 PM.


#30 Karpana OFFLINE  

Karpana

    Advanced Member

  • Members
  • 77 posts
  • Local time: 10:33 AM

Posted 14 May 2019 - 09:38 PM


To me there is still a permission issue, but it is odd it only affect bif files though.

2019-05-14 17:35:41.864 Error App: Error creating thumbnails for /mnt/nas/lithium/videos/TestMedia/Escape Room (2019)/Escape Room (2019) [Bluray-720p].mp4

System.UnauthorizedAccessException: System.UnauthorizedAccessException: Access to the path is denied. ---> System.IO.IOException: Operation not permitted


As noted in a previous post, the entire nas share is mounted with full read/write access (777 in Unix bitwise)

#31 Karpana OFFLINE  

Karpana

    Advanced Member

  • Members
  • 77 posts
  • Local time: 10:33 AM

Posted 20 May 2019 - 04:18 PM

I tried to downgrade the installation to 4.1.0.23, but I can't find the .rpm file anywhere.
It's not in the normal path on the internet which I would have hoped to find here.
My plan had been to try and rule the issue as something that happened since that version.

 

Instead, I installed the current "public" release (4.1.1.0) and was able to confirm that the issue is still there.

I then installed the current beta (4.2.0.6) and confirmed that the issue still persists.

 

Working from what @Happy2Play mentioned a few days ago, I decided to explore the permissions in detail.

 

this is what I have from the root directory.  I'm only including relevant/pertinent information to the path in question, even though this issue is affecting both primary paths for my libraries (movies & TV Shows).

/
	drwxr-xr-x.   3 root root     17 Jan 25 19:11 mnt
	dr-xr-xr-x.  17 root root    242 Apr 29 20:03 ..
	dr-xr-xr-x.  17 root root    242 Apr 29 20:03 .

/mnt
	drwxr-xr-x.  3 root root  17 Jan 25 19:11 .
	drwxr-xr-x.  3 root root  21 Jan 25 19:11 nas
	dr-xr-xr-x. 17 root root 242 Apr 29 20:03 ..

/mnt/nas
	drwxr-xr-x. 3 root root 17 Jan 25 19:11 ..
	drwxr-xr-x. 3 root root 21 Jan 25 19:11 .
	drwxr-xr-x. 3 root root 20 Jan 25 19:13 lithium

/mnt/nas/lithium
	drwxr-xr-x. 3 root root   21 Jan 25 19:11 ..
	drwxr-xr-x. 3 root root   20 Jan 25 19:13 .
	drwxrwxrwx. 2 5000 6000 8192 May 20 14:55 videos

/mnt/nas/lithium/videos
	drwxr-xr-x. 3 root root       20 Jan 25 19:13 ..
	drwxrwxrwx. 2 5000 6000        0 May 16 22:59 TV Shows
	drwxrwxrwx. 2 5000 6000     8192 May 20 14:55 .

/mnt/nas/lithium/videos/TV Shows
	drwxrwxrwx. 2 5000 6000 40960 May 16 22:59 .
	drwxrwxrwx. 2 5000 6000  8192 May 20 14:55 ..
	drwxrwxrwx. 2 5000 6000     0 Apr 23 17:55 Star Trek - Discovery

/mnt/nas/lithium/videos/TV Shows/Star Trek - Discovery
	drwxrwxrwx. 2 5000 6000   4096 Apr 23 17:55 .
	drwxrwxrwx. 2 5000 6000  40960 May 16 22:59 ..
	drwxrwxrwx. 2 5000 6000      0 May 20 14:43 Season 02

/mnt/nas/lithium/videos/TV Shows/Star Trek - Discovery/Season 02
	drwxrwxrwx. 2 5000 6000       4096 Apr 23 17:55 ..
	drwxrwxrwx. 2 5000 6000      24576 May 20 14:43 .

I then proceeded to load another TV show in to my TV Show library, organized in much the same manner.

I can confirm that this new TV show was successfully able to create

  • <filename>-thumb.jpg
  • <filename>.en.srt

It is also successfully, in the TV show's "root" folder, successfully creating these files

  • banner.jpg
  • fanart.jpg
  • landscape.jpg
  • logo.png
  • poster.jpg
  • seasonX-poster.jpg

But was unsuccessful at creating the <filename>.bif file(s)

 

If as @Luke and @Happy2Play have asserted, that this is in fact a permissions issue,

  1. Why is it only affecting the .bif file creation?
  2. How do I go about determining what credential the "bif file creation" is running under so that I can review that specific credential's permissions. 

 

 



#32 Karpana OFFLINE  

Karpana

    Advanced Member

  • Members
  • 77 posts
  • Local time: 10:33 AM

Posted 23 May 2019 - 07:31 AM   Best Answer

@Luke & @Happy2Play

I have some fortuitous news to report.
It seems I've gotten this to work, though for the life of me, I can't explain why this solution was necessary.

Yesterday, on a whim, I disabled the "save thumbnails to media folder" option on one of my libraries and forced the TV episode in question to update missing metadata.
The .bif file was successfully created in the /emby/metadata folder.

I re-enabled the option to save thumbnails to media folder (and deleted the bif file in metadata) and it again failed.

the only "real" difference between the /metadata folder area and my media folder is who owned the folder. 

Keeping in mind that my media folder is mounted from my NAS, I recognized I have some control about which owner/group (on the CentOS side) the NAS is mounted as.

I went into my /etc/fstab file, changed the uid&gid from 5000/6000 (which was working through emby 4.1.0.23) and works for all everything but .bif files and changed it to 997/994 (emby's user and group).
I unmounted the NAS from CentOS and remounted it.

I then forced emby to update missing metadata, and much to my surprise, it worked!

As indicated, I can't explain why this worked, but it has.

I have a bit more testing, specifically around the creation of other files and functionality validation.  But for the time being this is a fortuittous start.


This is what my directory structure permissions look like now (note the 5000/6000 is now showing emby/emby)
I guess with this change, assuming everything else checks out, I should be able to reduce permissions *away* from 777.

I'll send an update in the next few days to let you know how everything else is holding up.

/
	drwxr-xr-x.   3 root root     17 Jan 25 19:11 mnt
	dr-xr-xr-x.  17 root root    242 Apr 29 20:03 ..
	dr-xr-xr-x.  17 root root    242 Apr 29 20:03 .

/mnt
	drwxr-xr-x.  3 root root  17 Jan 25 19:11 .
	drwxr-xr-x.  3 root root  21 Jan 25 19:11 nas
	dr-xr-xr-x. 17 root root 242 Apr 29 20:03 ..

/mnt/nas
	drwxr-xr-x. 3 root root 17 Jan 25 19:11 ..
	drwxr-xr-x. 3 root root 21 Jan 25 19:11 .
	drwxr-xr-x. 3 root root 20 Jan 25 19:13 lithium

/mnt/nas/lithium
	drwxr-xr-x. 3 root root   21 Jan 25 19:11 ..
	drwxr-xr-x. 3 root root   20 Jan 25 19:13 .
	drwxrwxrwx. 2 emby emby 8192 May 20 14:55 videos

/mnt/nas/lithium/videos
	drwxr-xr-x. 3 root root       20 Jan 25 19:13 ..
	drwxrwxrwx. 2 emby emby        0 May 16 22:59 TV Shows
	drwxrwxrwx. 2 emby emby     8192 May 20 14:55 .

/mnt/nas/lithium/videos/TV Shows
	drwxrwxrwx. 2 emby emby 40960 May 16 22:59 .
	drwxrwxrwx. 2 emby emby  8192 May 20 14:55 ..
	drwxrwxrwx. 2 emby emby     0 Apr 23 17:55 Star Trek - Discovery

/mnt/nas/lithium/videos/TV Shows/Star Trek - Discovery
	drwxrwxrwx. 2 emby emby   4096 Apr 23 17:55 .
	drwxrwxrwx. 2 emby emby  40960 May 16 22:59 ..
	drwxrwxrwx. 2 emby emby      0 May 20 14:43 Season 02

/mnt/nas/lithium/videos/TV Shows/Star Trek - Discovery/Season 02
	drwxrwxrwx. 2 emby emby       4096 Apr 23 17:55 ..
	drwxrwxrwx. 2 emby emby      24576 May 20 14:43 .


#33 cayars OFFLINE  

cayars

    Advanced Member

  • Alpha Testers
  • 2945 posts
  • Local time: 11:33 AM

Posted 23 May 2019 - 10:08 AM

forced the TV episode in question to update missing metadata"

 

Do that again after the changes so it can determine the BIF file is no longer present and set it up to be created again for you on the next BIF generation run.



#34 Karpana OFFLINE  

Karpana

    Advanced Member

  • Members
  • 77 posts
  • Local time: 10:33 AM

Posted 23 May 2019 - 12:05 PM

@cayars,

Thanks for your reply.
I'm not quite sure what you're referring to, so I'll do a quick summary of this entire thread, as well as a variant recap of my last post.

 

------------------------------------------

I've been having a "long-standing" issue since I upgraded away from 4.1.0.23 where missing bif files were not being created.  @Luke and @Happy2Play have both said it's a permissions issue, but couldn't explain why it was affecting just the .bif files.

I've been doing my own investigation since April 23rd (which is when I detected it), but it had been occuring since April 9th when I upgraded away from 4.1.0.23.

The way I've been testing is to go to an individual TV episode I knew to be missing a .bif file, clicking on the "triple dots", clicking "refresh metadata" and instructing Emby to do a "search for missing metadata".  This has been consistently "failing" since I started this ticket on April 23rd.  This series of steps is what I've been referring to as "force bif file creation".

After poking at the system and trying my own things, the activities completed yesterday were

  • Try the "force bif file creation" after upgrading to 4.2.07
    • Resulted in failure
  • Change the library's setting so as to not store BIF files in the media directory
  • Try the "force bif file creation"
    • Resulted in success, but the file was in the "global" metadata folder and not the media folder
  • manually deleted the .bif file from the global metadata folder
  • Changed the library setting back so as to store BIF files in the media directory
  • Try the "force bif file creation"
    • Resulted in failure
  • Stop the Emby Server
  • Unmounted my NAS from my CentOS Server
  • Change the UID/GID that the NAS was mounted to my CentOS Server to use Emby's uid and gid
  • Remouted my NAS to my CentOS server
  • Started the Emby Sever
  • Try the "force bif file creation"
    • Resulted in success, with the bif file in the media folder.
  • I then tried an "force bif file creation" on three more pieces of media that were missing BIF files
    • resulted in success

------------------------------------------

 

Given this apparent success, before I left for work (and after posting my earlier update for @Luke and @Happy2Play), I started library level "search for missing metadata" on both my TV Shows and movies libraries, and have been monitoring the log file remotely most of the morning thus far.

All in all, from about 6:35am local time through 9:21am, my server has scanned through both libraries and appears, per the logs, to have done the thumbnail creation process (aka created .bif files) 200 times. 

A quick scan of the command lines in the log file, indicates that emby seems to have found obvious titles that I know were missing .bif files.

I still need to do some other validation/testing that the rest of the feature stack is working.  For example I see one recurring error in the logs about "PlaybackMonitoringTask", that I want to look at closer.
 

But all in all, it appears that when mounting SMB shares to CentOS, it is important for it to be mounted as the emby uid and gid.

 

 



#35 cayars OFFLINE  

cayars

    Advanced Member

  • Alpha Testers
  • 2945 posts
  • Local time: 11:33 AM

Posted 23 May 2019 - 01:55 PM

Scan for missing meta-data is what I was referring to vs the new file scan.

 

I think this needs improvement all around so that a normal scan determines if a BIF is present or not and allows the scheduled task (or integrated with scan) of creating BIF files to happen without searching for missing meta-data or other mechanism that might be needed.


Edited by cayars, 23 May 2019 - 01:58 PM.


#36 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 137605 posts
  • Local time: 11:33 AM

Posted 23 May 2019 - 02:02 PM

Scan for missing meta-data is what I was referring to vs the new file scan.

 

I think this needs improvement all around so that a normal scan determines if a BIF is present or not and allows the scheduled task (or integrated with scan) of creating BIF files to happen without searching for missing meta-data or other mechanism that might be needed.

 

That's out of scope of this particular topic. Thanks.


  • cayars and Karpana like this

#37 Karpana OFFLINE  

Karpana

    Advanced Member

  • Members
  • 77 posts
  • Local time: 10:33 AM

Posted 23 May 2019 - 05:37 PM

So a quick question for @Luke and @Happy2Play:

I'm no expert on Linux, by any stretch of the imagination, but I'm wondering if either of you have any ideas on why having the "owner" and/or "group" (not sure which) not matching emby's user/group on the media folder would cause this problem?

 

Suffice to say, it seems like the problem is solved (at least insofar as being able to create .bif files), though I haven't had enough time to poke at it to confirm nothing else is affected.



#38 Happy2Play OFFLINE  

Happy2Play

    Trial and Error

  • Moderators
  • 15626 posts
  • Local time: 08:33 AM
  • LocationWashington State

Posted 23 May 2019 - 06:09 PM

Sorry I have relatively no knowledge of Linux.  But the oddest thing to me is other items can be written, so why would a bif file not.  Is there some sort of file type restrictions somewhere?



#39 Karpana OFFLINE  

Karpana

    Advanced Member

  • Members
  • 77 posts
  • Local time: 10:33 AM

Posted 23 May 2019 - 08:35 PM

It's not anything I've ever seen in my 20 years of working with *Nix systems.

Plus as previously noted, it was working fine under 4.1.0.23.

Just super strange.



#40 Karpana OFFLINE  

Karpana

    Advanced Member

  • Members
  • 77 posts
  • Local time: 10:33 AM

Posted 27 May 2019 - 08:13 PM

Wanted to do one final check in.

Thus far, nothing out of the ordinary has cropped since I made the mounting changes.







Also tagged with one or more of these keywords: centos, Roku, linux, thumbnail

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users