mherger wrote: 
> >> I'm confused by the tmp:/// designation in the URL of the track
> location
> >> as I also see file:/// used which would seem more appropriate. To
> avoid
> >> a future problem under what conditions would the tmp:/// designation
> be
> >> used by LMS?
> >>
> > 
> > I don't know why that designation is being used in your case. I see
> it
> > whenever I have items in the current playlist that were put there
> before
> > a full rescan. Pure speculation on my part, but I assume that since
> the
> > database has been rebuilt, the old track ID is no longer correct. So
> LMS
> > creates a temporary link to use and discards it as soon as the track
> as
> > been played or the playlist cleared.
> 
> In general the "volatile tracks" using the tmp:// protocol are handled 
> like regular file URLs, except that these items are not stored in the 
> database. It's what makes eg. the "browse filesystem" feature possible.
> 
> And continuing to play your current playlist while a wipe & rescan is 
> going on: in this situation we don't want to write to the database from
> 
> the server part, to let the scanner have full control over it. So your 
> guess comes pretty close.
> 
> So one question probably is why you'd have tmp:// URLs in a playlist. 
> Maybe they're pointing at files that no longer exist?

My experience is that when a full rescan is done the current
clientplaylists in /var/lib/squeezeboxserver/prefs are first rewritten
to change the track references to use tmp:// urls (the previous
references were file pathnames including spaces and other special
characters). Then while the scan continues, the client playlists in the
browser disappear. After the scan is finished the tmp:// urls are still
there and the playlist is still not displayed. Note that all the clients
are squeezelite clients except for a Squeezebox v3 and a Touch but they
all exhibit the same behavior. If the tmp:// urls are supposed to be
replaced by file:// urls or file pathnames after the scan completes,
maybe the coderef error(s) are preventing the rewrite of the
clientplaylists.

In my tests I don't remove or change any files so all the references are
still valid AFAICT.

Are there other tests or logging settings I could use to try and figure
out if I have a problem with a track or album name that is causing these
problems?


------------------------------------------------------------------------
zeke1831's Profile: http://forums.slimdevices.com/member.php?userid=71469
View this thread: http://forums.slimdevices.com/showthread.php?t=114177

_______________________________________________
Squeezecenter mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/squeezecenter

Reply via email to