search

owntone / owntone-server

Linux/FreeBSD DAAP (iTunes) and MPD audio server with support for AirPlay 1 and 2 speakers (multiroom), Apple Remote (and compatibles), Chromecast, Spotify and internet radio.
https://owntone.github.io/owntone-server
GNU General Public License v2.0
2.09k stars 234 forks source link

Skip scanning m3u files / static playlists? #297

Closed feretio closed 8 years ago

feretio commented 8 years ago

I have a rather large collection (about 225,000 files) which takes almost 24 hours to scan before forked-daapd is usable. It seems to only take about 30 minutes to scan just the mp3 files and I can live without the playlists with my daapd client. I'm presuming the part in the logs that reads "scan: Scanned xxxx files..." is where it scans for new mp3 files. Is there some way to skip scanning the static playlists, preferably without having to compile it myself?

I tried adding .m3u to filetypes_ignore but that doesn't seem to do it. I'm running Ubuntu 16.04 and the forked-daapd v23.3-1 package installed.

Thanks!

ejurgensen commented 8 years ago

You could try setting "filescan_disable" to true. I think that will skip both scanning and playlist processing. Not 100% sure though :-) Should be ok if you don't change your library while forked-daapd isn't running.

Let me know if it does the trick.

feretio commented 8 years ago

Hi,

I thought about that but I'm frequently adding files to the library. Also, after a reboot, sometimes I see a SIGHUP signal in the forked-daapd log file and it stops processing, usually about halfway through. This wouldn't be so bad if it didn't take so long to scan the static playlists. I take it there's no way to tell forked-daapd to not scan for m3u files?

Thanks!

ejurgensen commented 8 years ago

I made a little change, so now the config option "filetypes_ignore" should work for m3u. However, using this option means that the m3u's will not be indexed at all. So the playlists won't be served in any way by forked-daapd.

For a library of your size, I still think you should consider using "filescan_disable" instead. You said, that you frequently add files, but my question was actually: Do you add files while forked-daapd is not running? Since you mention rebooting, I gather you probably run forked-daapd as a system service, which would mean that forked-daapd is watching your library at all times (also if you have disabled filescan). So you won't loose anything from disabling filescan, but will make forked-daapd start much quicker, and will also solve the SIGHUP (which might come from some OS startup daemon killing forked-daapd, because it decides forked-daapd is unresponsive for too long during startup).

And even if you do add files while forked-daapd is not running, it might still be a good idea to use "filescan_disable" for a library your size, and then just use "touch" to trigger partial filescans.

feretio commented 8 years ago

Thanks! I presume I would need to recompile (or compile it myself since I'm using a package from a repository) to see the change.

In the meantime, are you saying that if I set filescan_disable, forked-daapd will automatically check for new files while it's running? If so, you're right in that might be a good option.

I've read about touching the trigger.init-rescan and trigger.full-rescan but is there a way to simply tell forked-daapd to only look for new files?

ejurgensen commented 8 years ago

Yes, while forked-daapd is running it will find new files all by itself. It will also automatically detect if a file changes. You don't need to do anything, and this is independent of any config settings. This works because the OS will tell forked-daapd that a new file has appeared/changed. Note: This only works if your library is on a local filesystem. If it is on a remote/network filesystem then the OS will not know about the change, and so cannot notify forked-daapd (and in that case you need to look into init-rescan - see the README).

Yes, to get my change for filetypes_ignore you would need to compile yourself.