Jump to content

Search the Community

Showing results for tags 'rescan'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General
    • Announcements
    • Emby Premiere Purchase/Subscription Support
    • Feature Requests
    • Tutorials and Guides
  • Emby Server
    • General/Windows
    • Android Server
    • Asustor
    • FreeBSD
    • Linux
    • NetGear ReadyNAS
    • MacOS
    • QNAP
    • Synology
    • TerraMaster NAS
    • Thecus
    • Western Digital
    • DLNA
    • Live TV
  • Emby Apps
    • Amazon Alexa
    • Android Mobile
    • Android TV / Fire TV
    • Emby Theater
    • iOS
    • Apple TV
    • Kodi
    • Raspberry Pi
    • Roku
    • Samsung Smart TV
    • Sony PlayStation
    • LG Smart TV
    • Web App
    • Windows Media Center
    • Plugins
  • Language-specific support
    • Arabic
    • Dutch
    • French
    • German
    • Italian
    • Portuguese
    • Russian
    • Spanish
    • Swedish
  • Community Contributions
    • Ember for Emby
    • Fan Art & Videos
    • Tools and Utilities
    • Web App CSS
  • Other
    • Non-Emby General Discussion
    • Developer API
    • Hardware
    • Media Clubs
    • Legacy Support


  • Emby Blog

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...

Found 1 result

  1. Ever since version 3.0.6020, my library has been experiencing excessively long rescans. The library is placed on an SMB share on a ZFS filesystem, running OpenIndiana (and IllumOS variant based on Solaris), under VMWare ESXi 6. Emby Server runs under Windows 2008 R2 on the same ESXi machine. This was not a problem before version 3.0.6020. Scans were done in reasonable times (only a couple of minutes, with 30 TBs worth of movies and TV shows - only a thousand titles and episodes). Dozens of entries like these are showing up in the log on rescans, and ffprobe and ffmpeg always run when I restart the server or manually scan the library: 2016-08-12 15:46:43.1079 Debug App: Date modified for \\HORZA\media\Movies\Test Patterns\SPEARS & MUNSIL HIGH DEFINITION BENCHMARK. Old date 1/1/0001 7:00:00 AM new date 1/1/0001 12:00:00 AM Id 831db1b9-5636-cb27-ac17-8261a390e2b2 2016-08-12 15:46:43.1079 Debug ProviderManager: Saving \\HORZA\media\Movies\Test Patterns\SPEARS & MUNSIL HIGH DEFINITION BENCHMARK to Nfo. 2016-08-12 15:46:43.1079 Debug App: Saving \\HORZA\media\Movies\Test Patterns\SPEARS & MUNSIL HIGH DEFINITION BENCHMARK to database. I think it's related to the incorrect date being assigned to the entries, triggering ffmpeg/ffprobe to run all the time. This basically makes it impossible to use the server. Things I've tried: - using BulkFileChanger to force file modification time to be the same as file creation time (many of the files were copied, so file mod time was less than file creation time after the copy). - using touch command-line command to force all files in the library (several thousand files) to have the current date and time in the file modification date. - deleting library.db and refreshinfo.db and starting the server - changing all permissions on every file so that Everyone gets full control. ACL permissions set the same for every single file. - deleting all the xml and nfo files generated by Emby and starting the server to re-scan. If the "new date" is not misconstrued as 1/1/0001 12:00:00 AM then it doesn't get scanned again on restart. However, all the files/directories that are given the incorrect date of 1/1/0001 12:00:00 AM are always rescanned. This takes hours, and means I can not add any new content in a timely manner. Nothing seems to work! The only thing I haven't tried is moving the files off the server, onto a local hard drive, and copying back. That could take an entire day. Any ideas? Or should I give up on Emby?
  • Create New...