UMS excessive file scanning
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
UMS excessive file scanning
I started seeing this with UMS 3.1.x
When launching or restarting UMS, it happily sits idle in the background until I start a DLNA receiver (I use both PS3 and VLC). At that time UMS begins scanning every file in my shared folders. What the problem is, is it spends an extremely long time scanning MPG files. MKV files do not seem to be a problem. This scan will dig-in to the point that the renderer will time-out because it cannot display the folder contents. Because I have close to 3TB of media, this activity could take an hour or more.
I just tested UMS v3.0.0-a3 and the scan ran fairly quickly. Then tried again with v3.3.0 and it took forever. Tested with UMS cache both enabled and disabled.
Windows 7 x64
Java x64 1.7.0_45-b18
--Joe
When launching or restarting UMS, it happily sits idle in the background until I start a DLNA receiver (I use both PS3 and VLC). At that time UMS begins scanning every file in my shared folders. What the problem is, is it spends an extremely long time scanning MPG files. MKV files do not seem to be a problem. This scan will dig-in to the point that the renderer will time-out because it cannot display the folder contents. Because I have close to 3TB of media, this activity could take an hour or more.
I just tested UMS v3.0.0-a3 and the scan ran fairly quickly. Then tried again with v3.3.0 and it took forever. Tested with UMS cache both enabled and disabled.
Windows 7 x64
Java x64 1.7.0_45-b18
--Joe
Re: UMS excessive file scanning
I find that if i have a lot of media in one folder it does take a while for the media to show on the renderer in its list.
what i have done is built sub folders to be like "A-C" for all movies that begin with A, B and C... etc.. It helps.
what i have done is built sub folders to be like "A-C" for all movies that begin with A, B and C... etc.. It helps.
Please remember to Upload your debug logs!
Universal Media Server Wiki!
"...functionality before beautification..."
Re: UMS excessive file scanning
This is very annoying, I've enabled Caching, changed start javaw -Xmx to "1768M" and every time the app is started, all shared folders are re-scanned.
And there's no option in the GUI to stop that.
Sometimes the app simply hangs, using all CPU power and i have to forcibly "taskkill /im javaw.exe" and restart it.
So I've decided to change Log Level to Trace and once it will hang again i'll put a log to Pastebin so that hopefully the authors can solve the issue.
TV: LG 42LM660S, Win 8.1 x64
Core i7 4770, 32 Gb RAM
And there's no option in the GUI to stop that.
Sometimes the app simply hangs, using all CPU power and i have to forcibly "taskkill /im javaw.exe" and restart it.
So I've decided to change Log Level to Trace and once it will hang again i'll put a log to Pastebin so that hopefully the authors can solve the issue.
TV: LG 42LM660S, Win 8.1 x64
Core i7 4770, 32 Gb RAM
Re: UMS excessive file scanning
Two days and no hanging yet but it turned out that the debug.log file size is 1 Gb 
-
SharkHunter
- Developer
- Posts: 648
- Joined: Fri Jun 01, 2012 9:36 pm
Re: UMS excessive file scanning
If you would use any other media server you would have to scan folders to get anything to view. UMS scans as you go along. Don't put 2000 files in one folder that will for sure take ages to process. Or do a scan in the background over night.
We reject: kings, presidents and voting.
We believe in: rough consensus and running code.
We believe in: rough consensus and running code.
Re: UMS excessive file scanning
Hello Guys,
Some handbrake encoded records can't be parsed and appear as "The document {} couldn't be parsed. It will be covered up" where {} is the filename being referred to. Others function admirably and of course.
MediaInfo is impeccably equipped for parsing the record, at any rate calling "MediaInfo {}" from the order line yields a sizeable measure of data (connected for one of the terrible documents being referred to).
mediainfo1.txt
I had a snappy take a gander at the source code and the code being referred to src/principle/java/net/pms/dlna/RealFile.java at line 75 enters the if-condition in light of the fact that getMedia().getContainer() measures up to invalid for these documents, however lamentably I have no clue what this implies.
UMS 6.5.1-SNAPSHOT
MediaInfo v0.7.88
Linux 4.4.0-36-conventional #55-Ubuntu
Some handbrake encoded records can't be parsed and appear as "The document {} couldn't be parsed. It will be covered up" where {} is the filename being referred to. Others function admirably and of course.
MediaInfo is impeccably equipped for parsing the record, at any rate calling "MediaInfo {}" from the order line yields a sizeable measure of data (connected for one of the terrible documents being referred to).
mediainfo1.txt
I had a snappy take a gander at the source code and the code being referred to src/principle/java/net/pms/dlna/RealFile.java at line 75 enters the if-condition in light of the fact that getMedia().getContainer() measures up to invalid for these documents, however lamentably I have no clue what this implies.
UMS 6.5.1-SNAPSHOT
MediaInfo v0.7.88
Linux 4.4.0-36-conventional #55-Ubuntu