Bugzilla – Bug 9452
Preset button won't save Beatles album '1'
Last modified: 2009-07-31 10:29:43 UTC
Ok, this is a really odd one. I recently ripped an album by the Beatles called simply, '1'. I tried to save it as a preset. It won't and I get the following error in my logfile: [08-09-09 22:05:49.6790] Slim::Buttons::Common::__ANON__ (894) Error: No valid url found, not adding favorite! [08-09-09 22:05:49.6832] Slim::Buttons::Common::__ANON__ (896) do { my $a = { db => { findCriteria => { "album.id" => 365, "contributor.id" => 150 }, hierarchy => "album,track", level => 1, selectionCriteria => { "album.id" => 365, "contributor.id" => 150, "track.id" => 4055 }, }, jive => { actions => { add => { cmd => ["playlistcontrol"], params => { album_id => 365, cmd => "add" }, player => 0, }, "add-hold" => { cmd => ["playlistcontrol"], params => { album_id => 365, cmd => "insert" }, player => 0, }, go => { cmd => ["tracks"], params => { album_id => 365, menu => "songinfo", menu_all => 1, "sort" => "tracknum" }, }, play => { cmd => ["playlistcontrol"], params => { album_id => 365, cmd => "load" }, player => 0, }, "play-hold" => undef, }, playHoldAction => undef, window => { "icon-id" => 4055, text => 1, titleStyle => "album" }, }, name => "Album: 1", player => { mode => "browsedb", modeParams => 'fix' }, type => "redirect", value => "Album: 1", web => { group => "album", url => "browsedb.html?hierarchy=album,track&level=1&album.id=365&contributor.id=150", value => 1, }, }; $a->{player}{modeParams} = $a->{db}; $a; } Have I come across some kind of weird limit case?
Oops, again I was too fast. This happens in general if you are looking at the Now Playing information and then click down into the track information to album (artist, genre, year, etc), and then try to bookmark the album from this point. Seems like you should be able to bookmark something at this point as your have navigated to something specific.
On further testing, I can bookmark the Beatles album 1, but when I use a Boom preset or try to load it from the SC Favorites list, nothing happens. (Nothing in the logfile either, just an empty playlist.) Weird.
cc'ing triode in case this makes sense to him :)
I see similar problems with 7.3 nightly deb's.
I was unable to reproduce this using Led Zeppelin's '1' album on a MAC 10.5.x system with the latest 7.2.1-23353 build. Added album via WEB UI > Favorites Assigned it to Preset 1 Boom preset 1 button started album (In reply to comment #1) > This happens in general if you are looking at the > Now Playing information and then click down into the track information to album > (artist, genre, year, etc), and then try to bookmark the album from this point. > Seems like you should be able to bookmark something at this point as your have > navigated to something specific. > From the boom > Now Playing menu, holding down one of the preset buttons while the album is playing will result in the currently playing song is assigned to that preset value. This is the ONLY valid way to add currently streaming items to the preset using the BOOM UI. You can NOT drill down and add Artist / Album / Genre as you described. This is by design. -------- Ross: can you try this on a 7.2.1 Deb build please.
(In reply to comment #6) > Ross: can you try this on a 7.2.1 Deb build please. Works for me Ubuntu with 7.2.1. Preset plays the album just fine for me.
Since we haven't yet reproduced this in-house I'm moving it to 7.3
What about the users who HAVE seen the problem. Do either of you still see it in current 7.3 builds? There have been other fixes in the playing of favourites and url handling, so it may be corrected.
I still see the original issue. I don't know about Andrew's motivation, but I think that press-and-hold should save whatever is currently playing to the playlist. I think any other behavior is very confusing. There are some suggestions that the designed behavior does not match this. If I am in now-playing mode for a local album and press-and-hold, I get this stack trace: [08-11-07 13:12:40.0059] Slim::Buttons::Common::__ANON__ (834) Backtrace: frame 0: Slim::Utils::Log::logBacktrace (/usr/share/perl5/Slim/Buttons/Common.pm line 834) frame 1: Slim::Buttons::Common::__ANON__ (/usr/share/perl5/Slim/Hardware/IR.pm line 1104) frame 2: Slim::Hardware::IR::executeButton (/usr/share/perl5/Slim/Control/Commands.pm line 278) frame 3: Slim::Control::Commands::buttonCommand (/usr/share/perl5/Slim/Control/Request.pm line 1883) frame 4: (eval) (/usr/share/perl5/Slim/Control/Request.pm line 1883) frame 5: Slim::Control::Request::execute (/usr/share/perl5/Slim/Control/Request.pm line 866) frame 6: Slim::Control::Request::executeRequest (/usr/share/perl5/Slim/Player/Client.pm line 655) frame 7: Slim::Player::Client::execute (/usr/share/perl5/Slim/Hardware/IR.pm line 1125) frame 8: Slim::Hardware::IR::processCode (/usr/share/perl5/Slim/Hardware/IR.pm line 901) frame 9: Slim::Hardware::IR::fireHold (/usr/share/perl5/Slim/Utils/Timers.pm line 211) frame 10: (eval) (/usr/share/perl5/Slim/Utils/Timers.pm line 211) frame 11: Slim::Utils::Timers::checkTimers (/usr/sbin/squeezecenter-server line 542) frame 12: main::idle (/usr/sbin/squeezecenter-server line 484) frame 13: main::main (/usr/sbin/squeezecenter-server line 1046) However, if I have just recently hit play or if I am inside the Music Library-> hierarchy, press-and-hold works OK. I understand the technical reason for this, but I really do not think it is intuitive and I doubt the stack trace is really intended.
This issue appears to be a dup of bug 8503. if you feel differently, reopen this bug and explain why. *** This bug has been marked as a duplicate of bug 8503 ***
Reduce number of active targets for SC