Bugzilla – Bug 14008
Preset-setting broken in a few places (using IR Remote) and a suggestion
Last modified: 2010-04-09 17:33:24 UTC
Running 7.4 from unstable apt repo as of right now. Testing on an SB3, but I also have a Boom where I expect to see similar issues when using an IR remote. Steps to reproduce: 1. Tune to a pls URL, e.g. http://media.kcrw.com/live/kcrwnews.pls using the "Tune in URL" feature in the Web UI 2. Wait for NOW_PLAYING screensaver 3. Attempt to save preset by holding down a number on the remote 4. Fails, with these lines in server.log: [09-09-13 00:24:59.5962] Slim::Buttons::Common::__ANON__ (834) Error: No valid url found, not adding favorite! [09-09-13 00:24:59.5966] Slim::Buttons::Common::__ANON__ (836) "NOW_PLAYING" ---- Another variant: 1. Tune to a pls URL 2. Don't wait for NOW_PLAYING screensaver 3. Attempt to save preset 4. SB's screen reports preset saved 5. Preset not actually saved. I think at least one problem is that you can't save preset #10 when preset #9 isn't available. I tried setting preset #1 and I succeeded. But, I've had a problem here when all 10 presets were set and I wasn't able to replace #10 or any of the others. I've yet to figure out why. ---- Another variant: It's difficult to make random song playback a preset. If I play random songs and set a preset, it'll make the actual song a preset. If I go to "Music Library" -> "Random Mix" -> "Song Mix", it'll refuse to make a preset, with the following error: [09-09-13 01:19:03.0517] Slim::Buttons::Common::__ANON__ (834) Error: No valid url found, not adding favorite! [09-09-13 01:19:03.0521] Slim::Buttons::Common::__ANON__ (836) "track" If I go to "Favorites", I have "Random songs" as favorite #1, and in that case, I'm able to turn that into a preset. But if Random Song was fav #2, it wouldn't work, because hitting "2" goes to the 2nd favorite first. This is also a problem with setting preset #2 on the "Random Mix" screen too, or any other place where the number functions have that feature too. ---- The current UI also appears to make it impossible to set a preset for a station that's currently down. ---- Since I don't really need different presets for my different players, so far this feature is a regression for me, and will probably remain so even with all the bugs fixed. The optimal setup for me would be one where controlling the favorites menu would also affect all presets on all players, and vice versa. Simple and easy. The new way will be tolerable if the UI issues are worked out though :). And the previous preset UI wasn't so hot either, but it was at least possible to do what I wanted with it without stopping squeezeboxserver and hacking the prefs file. Oh and having 3 different modes for a number button (menu item shift, jump to preset, set preset) seems error-prone. I've gone the wrong way a couple of times on this already. Ooh, an idea... In squeezecenter 7.3 and earlier, favorites were one thing, remote control number buttons were favorites but rearranged oddly, and I think front-panel buttons were just the first 6 favorites (but I'm not sure because I just set favorite order == IR buttons == front panel buttons. In squeezeboxserver now, there are categories: "favorites" vs. per-client number presets where the remote control and the front-panel buttons are forced to be the same. My proposed change: favorites and IR number buttons are the same (either as done in SC 7.3, or just drop the extra selections and just make favorite #1 == IR button #1 which is my preference). Front-panel buttons are separate, per-client, and set by holding down the front-panel buttons until a web UI for that is developed. They'd be completely distinct from IR buttons. Someone might be confused about the front-panel buttons being different from the IR buttons. But, I claim this is not a problem, because players with front-panel buttons don't come with IR remotes with number buttons, so it's only the non-basic users who would even notice this. And it resolves confusion between favorite numbering in the menu and IR buttons, and those two are more closely related, I think. I think this would resolve some of the UI issues above. Thanks.
I think I figured out why the following problem was occurring: "But, I've had a problem here when all 10 presets were set and I wasn't able to replace #10 or any of the others. I've yet to figure out why." I'm guessing that setting a 10th preset can only be done by hacking the prefs file (which I did earlier as mentioned before), and breaks setting other presets somehow. For all the other bugs listed, I cleaned out my presets and started from scratch, and while adding all my presets back, was unable to add the 10th preset. I haven't dug through the code to figure out why for sure, but I think the logic in Slim::Player::Client::setPreset() is just subtracting 1 from the preset number, which might fail if considering the preset as #0 instead of #10.
Triode: Can you take a look at this one? I don't think you can save a preset when on the Now Playing screensaver, as the initial press of the remote will cancel the screensaver. You will end up saving the preset on the menu item you were previously on (which may or may not be allowed as a favorite). Using IR to set presets while in a menu is problematic too, because the initial press can jump you to a different item.
The real solution to this is to revert to merged favorites and preset so we can use all of the old methods for saving favorites... I realise there are problems with the IR based solution today. I don't see any easy way round this. I tried changing the menu code to use *.single events so that it did not trigger on long holds and this means that the current number based scrolling breaks in menus. The screensaver case will be the same I don't see any easy way to do something immdiately whilst also waiting for the hold event to see what we should do for a setting a preset. We need a different way of setting presets via the remote and the old favorites code seems the best mechanism we have got (plus a web UI to renumber them!)
We need to decide what to do for 7.4. The simplest solution is to remove the ability to set presets from IR. I think ultimately we'll need an IR-based context menu for this.
For non Boom Ip3k players this would mean there is no ability to set a preset and so a feature which has worked for several years would be removed! I think the current slightly compromised capability is better than this, but I do recommend going back to the favorites code for setting presets from button modes.
Favorites and presets aren't linked anymore, and it doesn't make sense to link them. So I don't have a solution. Maybe someone needs to build a web UI for setting presets for non-Boom ip3k players. But that's a lot of work.
Right - so what is in trunk today is better than removing it as it works for most cases rather than no cases?? I dont see any quick fixes for the issues raised here - it needs menus to be addded and the relavent ones are currently bound to favorites in each button mode.
I'm OK with leaving what's there for 7.4 and fixing this later.
OK - lets work on this for 8.0. I'm happy to look at some new menus and hence some new strings etc..
The easy fix for the original problem is to change the button mappings in Default.map from [common] 0 = numberScroll_0 1 = numberScroll_1 2 = numberScroll_2 3 = numberScroll_3 4 = numberScroll_4 5 = numberScroll_5 6 = numberScroll_6 7 = numberScroll_7 8 = numberScroll_8 9 = numberScroll_9 to [common] 0.single = numberScroll_0 1.single = numberScroll_1 2.single = numberScroll_2 3.single = numberScroll_3 4.single = numberScroll_4 5.single = numberScroll_5 6.single = numberScroll_6 7.single = numberScroll_7 8.single = numberScroll_8 9.single = numberScroll_9 since otherwise the menu will jump away from the current item before *.hold_release can fire.
Or to be precise, it solves the part of the problem where you can only assign favorite #1 to preset #1, favorite #2 to preset #2 etc., but not favorite #2 to preset #1. It does not solve the problem with the random mix.