Problem with listing dirs with large number of files
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
Problem with listing dirs with large number of files
Hi
I have a problem with clients erroring on directories with large number of files. It seems dependent on renderer, but not sure how to deal with it
ROKU box seems to work OK
Android - two clients with differing level of problem
slick UPNP - works with list with 768 files, but fails with more
Nova Video Player - fails with a lower number (around 300)
Both of these use the android renderer
UMS conf
language = en-GB
minimized = false
maximum_bitrate = 3000
mpeg2_main_settings = Automatic (Wired)
x264_constant_rate_factor = Automatic (Wired)
hide_advanced_options = false
scan_shared_folders_on_startup = true
folders = /srv/data/Downloads,/srv/data/staging,/srv/data/meta,/srv/data/playlists,/srv/porn,/srv/progs/programs,/srv/films/films/films
run_wizard = false
uuid = c2bf0587-0290-4db7-b3c4-d3da63fe3830
ffmpeg_available_gpu_acceleration_methods = none,auto,vdpau,cuda,vaapi,qsv,drm,opencl,vulkan
engines = FFmpegVideo,MEncoderVideo,tsMuxeRVideo,VLCVideo,FFmpegAudio,tsMuxeRAudio,FFmpegWebVideo,VLCWebVideo,VLCVideoStreaming,MEncoderWebVideo,VLCAudioStreaming,DCRaw
engines_priority = FFmpegVideo,MEncoderVideo,tsMuxeRVideo,VLCVideo,FFmpegAudio,tsMuxeRAudio,FFmpegWebVideo,VLCWebVideo,VLCVideoStreaming,MEncoderWebVideo,VLCAudioStreaming,DCRaw
folders_monitored = /srv/data/Downloads,/srv/data/staging,/srv/data/meta,/srv/data/playlists,/srv/porn,/srv/progs/programs,/srv/films/films/films
server_name = UMS capture
network_interface = eth0
hostname = 192.168.1.3
subs_info_level = none
show_server_settings_folder = true
show_new_media_folder = true
cred.path = /home/mike/.config/UMS/UMS.cred
logging_filter_logs_tab = DEBUG
logging_logs_tab_linebuffer = 3000
disable_subtitles = true
selected_renderers = Android, BubbleUPnP, Kodi, Roku, VLC, VideoWeb, XBMC
renderer_default = Android
thumbnail_seek_position = 30
hide_empty_folders = true
dvd_isos_thumbnails = false
renderer_force_default = true
external_network = true
google-android.conf
RendererName = Android
RendererIcon = android.png
UserAgentSearch = Android
UpnpDetailsSearch = Android
TranscodeAudio = MP3
DefaultVBVBufSize = true
MuxDTSToMpeg = true
H264Level41Limited = false
StreamExtensions = mkv,hdmov,hdm,flac,fla,dts,ogg,asf,asx,m2v,mp4,mpg,mpeg,avi,mov,wmv
ChunkedTransfer = true
HalveBitrate = true
MediaInfo = true
MaxVideoBitrateMbps = 30
# Supported video formats:
Supported = f:mpegts v:h264 a:aac-lc|lpcm|mp2|mp3 n:2 m:video/vnd.dlna.mpeg-tts
# Supported audio formats:
Supported = f:m4a m:audio/x-m4a
Supported = f:flac m:audio/x-flac
Supported = f:mp3 m:audio/mpeg
Supported = f:wav m:audio/wav
Supported = f:wma m:audio/x-ms-wma
Any ideas appreciated
I have a problem with clients erroring on directories with large number of files. It seems dependent on renderer, but not sure how to deal with it
ROKU box seems to work OK
Android - two clients with differing level of problem
slick UPNP - works with list with 768 files, but fails with more
Nova Video Player - fails with a lower number (around 300)
Both of these use the android renderer
UMS conf
language = en-GB
minimized = false
maximum_bitrate = 3000
mpeg2_main_settings = Automatic (Wired)
x264_constant_rate_factor = Automatic (Wired)
hide_advanced_options = false
scan_shared_folders_on_startup = true
folders = /srv/data/Downloads,/srv/data/staging,/srv/data/meta,/srv/data/playlists,/srv/porn,/srv/progs/programs,/srv/films/films/films
run_wizard = false
uuid = c2bf0587-0290-4db7-b3c4-d3da63fe3830
ffmpeg_available_gpu_acceleration_methods = none,auto,vdpau,cuda,vaapi,qsv,drm,opencl,vulkan
engines = FFmpegVideo,MEncoderVideo,tsMuxeRVideo,VLCVideo,FFmpegAudio,tsMuxeRAudio,FFmpegWebVideo,VLCWebVideo,VLCVideoStreaming,MEncoderWebVideo,VLCAudioStreaming,DCRaw
engines_priority = FFmpegVideo,MEncoderVideo,tsMuxeRVideo,VLCVideo,FFmpegAudio,tsMuxeRAudio,FFmpegWebVideo,VLCWebVideo,VLCVideoStreaming,MEncoderWebVideo,VLCAudioStreaming,DCRaw
folders_monitored = /srv/data/Downloads,/srv/data/staging,/srv/data/meta,/srv/data/playlists,/srv/porn,/srv/progs/programs,/srv/films/films/films
server_name = UMS capture
network_interface = eth0
hostname = 192.168.1.3
subs_info_level = none
show_server_settings_folder = true
show_new_media_folder = true
cred.path = /home/mike/.config/UMS/UMS.cred
logging_filter_logs_tab = DEBUG
logging_logs_tab_linebuffer = 3000
disable_subtitles = true
selected_renderers = Android, BubbleUPnP, Kodi, Roku, VLC, VideoWeb, XBMC
renderer_default = Android
thumbnail_seek_position = 30
hide_empty_folders = true
dvd_isos_thumbnails = false
renderer_force_default = true
external_network = true
google-android.conf
RendererName = Android
RendererIcon = android.png
UserAgentSearch = Android
UpnpDetailsSearch = Android
TranscodeAudio = MP3
DefaultVBVBufSize = true
MuxDTSToMpeg = true
H264Level41Limited = false
StreamExtensions = mkv,hdmov,hdm,flac,fla,dts,ogg,asf,asx,m2v,mp4,mpg,mpeg,avi,mov,wmv
ChunkedTransfer = true
HalveBitrate = true
MediaInfo = true
MaxVideoBitrateMbps = 30
# Supported video formats:
Supported = f:mpegts v:h264 a:aac-lc|lpcm|mp2|mp3 n:2 m:video/vnd.dlna.mpeg-tts
# Supported audio formats:
Supported = f:m4a m:audio/x-m4a
Supported = f:flac m:audio/x-flac
Supported = f:mp3 m:audio/mpeg
Supported = f:wav m:audio/wav
Supported = f:wma m:audio/x-ms-wma
Any ideas appreciated
Re: Problem with listing dirs with large number of files
You have to give more information of the nature of the "problem". There are two possible causes for issues with large folders that I can think of:
1) Timeout. UMS must "build" the complete "document" that is sent in response to a browse request before it responds, the UPnP protocol doesn't allow this to happen progressively, so for folders with a large number of media files this can take a substantial amount of time. Renderers have a timeout value, which the UPnP spec dictates that it should be around 30 seconds, but in my experience it's usually shorter. If the renderer decides that it has waited long enough while UMS is still building the "document", the renderer will probably serve you some kind of error or just "jump back" to where you were. If this is the case, trying to enter the folder again after giving it some time could work, as UMS will reuse some of the work it did from the last attempt making the second go a bit faster.
2) Renderer limit for the maximum number of media resources. There's not supposed to be any such limit according to the spec as far as I know, but many implementations have limitations in reality. There is a setting in UMS's renderer configuration that can make it make "fake folders" if the number of resources exceeds a certain threshold, but I'm not sure how well it works.
Some more information about what constitutes the "problem" might shed some light as to what the situation is.
1) Timeout. UMS must "build" the complete "document" that is sent in response to a browse request before it responds, the UPnP protocol doesn't allow this to happen progressively, so for folders with a large number of media files this can take a substantial amount of time. Renderers have a timeout value, which the UPnP spec dictates that it should be around 30 seconds, but in my experience it's usually shorter. If the renderer decides that it has waited long enough while UMS is still building the "document", the renderer will probably serve you some kind of error or just "jump back" to where you were. If this is the case, trying to enter the folder again after giving it some time could work, as UMS will reuse some of the work it did from the last attempt making the second go a bit faster.
2) Renderer limit for the maximum number of media resources. There's not supposed to be any such limit according to the spec as far as I know, but many implementations have limitations in reality. There is a setting in UMS's renderer configuration that can make it make "fake folders" if the number of resources exceeds a certain threshold, but I'm not sure how well it works.
Some more information about what constitutes the "problem" might shed some light as to what the situation is.