Bugzilla – Bug 13622
playlist has entries such as file:///fullpath/to/directory/ instead of artist-album
Last modified: 2009-10-20 08:17:44 UTC
When using a playlist in an alarm for Alarm Sound at some point in time instead of the 'nice name' it starts pointing to a file:/// name. The original 'nice name' playlist entry is no longer present and in the list of playlists at the end are present the file:// playlists. It seems to happen for all playlists that are involved in an alarm. Example: original playlist nice name: Oakenfold, Paul - Another World - Disc 1 now appears: file:///c/media/music/Oakenfole,%20Paul/Another%20World/Disc%201/ actual playlist: /c/media/music/Oakenfold, Paul/Another World/Disc 1/Oakenfold, Paul - Another World - Disc 1.m3u
QA to verify on 7.4
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
QA confirmed this is still and issue in 7.4. See attached image. Players will flash the //file://... on screen as the alarm starts as well, but then transition to normal meta data.
Created attachment 5700 [details] Image Error
QA - how can I reproduce this?
1. Set up an alarm. 2. Use an existing playlist for the Alarm Sound. 3. Wait a bit - maybe a couple of days - not sure 4. Check alarm and it now points to file:///directory instead of playlist originally selected 5. Original playlist no longer present and replaced by file:///directory entry
I have had some of my playlists for years. And all of them still look ok. And I'm using my alarms every day too... Are you using some 3rd party plugin?
The only plugin I intentionally installed is the one necessary for iPeng on the iPhone.
> The only plugin I intentionally installed is the one necessary for iPeng > on the iPhone. That shouldn't be the issue here (btw: if you're running the iPeng app from the app store, then you don't need that plugin).
I think you are right. I just bought the iPeng app from the app store. I was confusing my upgrade activity and trying out an alarm plugin on the NAS with installing other plugins. Here is the current Plugins directory content: nas-01:/usr/share/squeezecenter/Plugins# uname -a Linux nas-01 2.6.17.8ReadyNAS #1 Tue Jun 9 13:59:28 PDT 2009 padre unknown nas-01:/usr/share/squeezecenter/Plugins# ls -l total 4 drwxr-xr-x 5 root root 4096 Jul 20 2008 iPeng nas-01:/usr/share/squeezecenter/Plugins#
QA - what you describe (temporary display of the playlist name) is not the same as the reporter says. In his case the playlist name is changed in eg. the playlist selector box. I cannot reproduce this.
See the screen shot attached to Comment #4
I'll try comment 6 instructions
Chris wanted to investigate this one.
James, is there a faster way to repro this than setting lots of alarms or waiting for it to go off each day?
James is there a faster way to repro this?
Ah never mind; I see this now on my Windows PC. I set two alarms over the course of 11 minutes. This was with build 28487. Michael did you look at James's image? It was very helpful to me in understanding the actual bug.
> Michael did you look at James's image? It was very helpful to me in > understanding the actual bug. Sure I did. But I've never seen it happen. Using alarms for >4 years. Every day. Do you have simple steps for re-production? Something reliable? How did you set those alarms?
== Auto-comment from SVN commit #28508 to the slim repo by michael == == https://svn.slimdevices.com/slim?view=revision&revision=28508 == Bug: 13622 Description: don't evaluate playlist title every time we read the list of playlists. Just return the value stored in the DB.
I can imagine the repeated re-evaluation of playlist names _might_ have returned incorrect values under certain conditions. As I've never been able to reproduce this problem I can't say whether it really is fixed. But I hope so. Going to close this bug. Please re-open immediately if you encounter this issue again. Thanks!
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Patiently waiting for ReadyNas 7.4.0 release...
Please give 7.4.1 a try - 7.4.0 for ReadyNAS was broken. http://downloads.slimdevices.com/nightly/?version=7.4 Though I'm not sure this issue really is fixed: http://forums.slimdevices.com/showthread.php?t=68640 Please re-open if it's not. Thanks!
*** Bug 14771 has been marked as a duplicate of this bug. ***
Reopend based on bug 14771 and Forum post http://forums.slimdevices.com/showthread.php?t=68640 Gary: can you please test SBS 7.4.1 to see if this resolves the issue for you?
Email from Gary: have been running 7.4.1 for a couple of weeks, just installed today's nightly, will rescan and try again :) -------------------------------------------------- hi again, rescanned tested alarm still doing the same thing :o(
When you saw this renaming happen, was there a scan running in the background? Or did you rescan after you set the alarm?
Ok, the alarm has to actually fire. Now I'm seeing it too.
Created attachment 6168 [details] --player.playlist log when alarm fired at 14:05
== Auto-comment from SVN commit #28916 to the slim repo by michael == == https://svn.slimdevices.com/slim?view=revision&revision=28916 == Fixed Bug: 13622 Description: don't fall back to using the alarm's playlist url if no title is defined. This resulted in renamed playlists. Just let the playlist parser do its job in this case.
Verified fixed in 7.4.1 r28916