mirror of
https://github.com/owntone/owntone-server.git
synced 2025-11-07 04:42:58 -05:00
add scan_type directive for doing brute-force scans
This commit is contained in:
@@ -2,6 +2,14 @@
|
||||
#
|
||||
# This is the mt-daapd config file.
|
||||
#
|
||||
# If you have problems or questions with the format of this file,
|
||||
# direct your questions to rpedde@users.sourceforge.net.
|
||||
#
|
||||
# You can also check the website at http://mt-daapd.sourceforge.net,
|
||||
# as there is a growing documentation library there, peer-supported
|
||||
# forums and possibly more.
|
||||
#
|
||||
|
||||
|
||||
#
|
||||
# web_root (required)
|
||||
@@ -39,7 +47,9 @@ db_dir /var/cache/mt-daapd
|
||||
#
|
||||
# mp3_dir (required)
|
||||
#
|
||||
# Location of the mp3 files to share
|
||||
# Location of the mp3 files to share. Note that because the
|
||||
# files are stored in the database by inode, these must be
|
||||
# in the same physical filesystem.
|
||||
#
|
||||
|
||||
mp3_dir /mnt/mp3
|
||||
@@ -49,7 +59,7 @@ mp3_dir /mnt/mp3
|
||||
#
|
||||
# This is both the name of the server as advertised
|
||||
# via rendezvous, and the name of the database
|
||||
# exported via DAAP
|
||||
# exported via DAAP. Also know as "What shows up in iTunes".
|
||||
#
|
||||
|
||||
servername mt-daapd
|
||||
@@ -74,9 +84,9 @@ runas nobody
|
||||
# See the mt-daapd.playlist file in the
|
||||
# contrib directory for syntax and examples
|
||||
#
|
||||
# Note that static playlists will still
|
||||
# show up, even if this directive is not
|
||||
# specified
|
||||
# This doesn't control static playlists... these
|
||||
# are controlled with the "process_m3u" directive
|
||||
# below.
|
||||
#
|
||||
|
||||
playlist /etc/mt-daapd.playlist
|
||||
@@ -101,6 +111,7 @@ playlist /etc/mt-daapd.playlist
|
||||
# play them. Perhaps this would be useful on Linux with
|
||||
# Rhythmbox, once it understands daap. (hurry up!)
|
||||
#
|
||||
#
|
||||
|
||||
extensions .mp3,.m4a,.m4p
|
||||
|
||||
@@ -145,28 +156,66 @@ extensions .mp3,.m4a,.m4p
|
||||
# If background rescanning is disabled, a scan can still be forced from the
|
||||
# "status" page of the administrative web interface
|
||||
#
|
||||
# Note that right now this is considered EXPERIMENTAL!
|
||||
#
|
||||
# Setting a rescan_interval lower than the time it takes to rescan
|
||||
# won't hurt anything, it will just waste CPU, and make connect times
|
||||
# to the daap server longer.
|
||||
#
|
||||
# There may be memory leaks here. If you see evidence of leaks, please
|
||||
# let me (rpedde@users.sourceforge.net) know.
|
||||
#
|
||||
|
||||
#rescan_interval 300
|
||||
|
||||
# always_scan
|
||||
#
|
||||
# always_scan
|
||||
#
|
||||
# The default behavior is not not do background rescans of the filesystem
|
||||
# unless there are clients connected. The thought is to allow the drives
|
||||
# to spin down unless they are in use. This might be of more importance
|
||||
# in IDE drives that aren't designed to be run 24x7.
|
||||
#
|
||||
# Forcing a scan will always work though, even if no users are connected.
|
||||
#
|
||||
#
|
||||
# The default behavior is not not do background rescans of the
|
||||
# filesystem unless there are clients connected. The thought is to
|
||||
# allow the drives to spin down unless they are in use. This might be
|
||||
# of more importance in IDE drives that aren't designed to be run
|
||||
# 24x7. Forcing a scan through the web interface will always work
|
||||
# though, even if no users are connected.
|
||||
|
||||
# always_scan 0
|
||||
|
||||
#
|
||||
# process_m3u
|
||||
#
|
||||
# By default m3u processing is turned off, since most m3u files
|
||||
# sitting around in peoples mp3 directories have bad paths, and
|
||||
# I hear about it. :)
|
||||
#
|
||||
# If you are sure your m3u files have good paths (i.e. unixly pathed,
|
||||
# with relative paths relative to the directory the m3u is in), then
|
||||
# you can turn on m3u processing by setting this directive to 1.
|
||||
#
|
||||
# I'm not sure "unixly" is a word, but you get the idea.
|
||||
#
|
||||
|
||||
# process_m3u 0
|
||||
|
||||
#
|
||||
# scan_type
|
||||
#
|
||||
#
|
||||
# This sets how aggressively mp3 files should be scanned to determine
|
||||
# file length. There are three values:
|
||||
#
|
||||
# 0 (Normal)
|
||||
# Just scan the first mp3 frame to try and calculate size. This will
|
||||
# be accurate for most files, but VBR files without an Xing tag will
|
||||
# probably have wildly inaccurate file times
|
||||
#
|
||||
# 1 (Aggressive)
|
||||
# This checks the bitrates of 10 frames in the middle of the song.
|
||||
# This will still be inaccurate for VBR files without an Xing tag,
|
||||
# but they probably won't be quite as inaccurate as 0. This takes
|
||||
# more time, obviously, although the time hit will only happen the
|
||||
# first time you scan a particular file.
|
||||
#
|
||||
# 2 (Painfully aggressive)
|
||||
# This walks through the entire song, counting the number of frames.
|
||||
# This should result in accurate song times, but will take the most
|
||||
# time. Again, this will only have to be incurred the first time
|
||||
# the file is indexed.
|
||||
#
|
||||
|
||||
# scan_type 0
|
||||
|
||||
|
||||
Reference in New Issue
Block a user