Bugzilla – Bug 4956
server title format can affect player title format
Last modified: 2009-09-08 09:18:15 UTC
I have my SB3 title format set to "TITLE - ALBUM - ARTIST" so that I get all of that information on the device's display. However, it appears that Fishbone uses that format in its status display, on the first line. The result is silly, since it's way too long for the window and the album and artist information is repeated just below. (Actually, I guess I'm just assuming that it's the same format string, since the effect is the same... but right now, I can't get it to change. Perhaps that's because it caches a compiled form.) The format makes sense for Default, since Default doesn't display the album and artist separately. I've got a fix, of sorts. I added a new parameter "baretitle" that's just $track->title, and changed Fishbone to use it. I don't know whether that's really the right fix, but it has the right effect, fixing Fishbone without breaking anything else.
Why not leave the web titleformat as just TITLE and set the player format to TITLE - ALBUM - ARTIST there is a titleformat setting in server settings , formatting(for web UI) and another in player settings (for player UI)
Because that would be too easy. Duh. I don't know whether it was just coincidence that the web format matched the player format, or if I changed both of them and then forgot that there were two separate parameters, or what. It might still be desirable to allow for multiple formats for use with different skins, but that seems like a corner case, and an opportunity to go insane with per-skin settings. Unless you think it'd be worth pursuing, I'm inclined to close this INVALID.
It can happen. The player setting is an index based on the list set up in the server settings. If you happen to change the active item from server settings, then you affect both. There might be room for tweaking the description to make people aware of this, so I'll leave this open for QA to review. changing the summary to better reflect the issue.
I don't think that's what I did. I wouldn't have *changed* an entry in the table; I would have *added* an entry. Still, perhaps the descriptions of the parameters could make their relationship more clear. Hmm. Are these really tied together? My player settings "TITLE FORMAT" list has 6 entries. My server settings / Formatting "TITLE FORMAT" list has 11 entries. Based on your description, I would have expected them to have the same list.
The list of options is created in server settings. The player settings is a list of pulldowns. Each pulldown should contain the same options as the list created in server settings. The player setting, however, serves a dual purpose. The radio button selects the "active" format option and the list sets the formats available to the player for the "titleFormat" button command. This command is ancient and is not connected to the current remote (it was on the old Sony remotes) It's probably much simpler to just get rid of both lists in favour of a single pref for server and player. Much of the web ui is really designed around having just TITLE as the format so my personal stance would be to do away with the server setting altogether and leave the player setting as a single item chosen from a list of standard options. There is always Michael Hergers' MusicInfo screensaver for the really fancy player display options.
Ah, so 'tis. I'm not paying careful enough attention, sorry. I see it now. I'm inclined to agree that the web UIs should just use TITLE. (Though I can see arguments for flexibility; the Default skin shows *only* [% songtitle %] and it'd be nice to be able to get it to show more.) I very much like that you can create your own formats to show on the player. Screen real estate on the player is more precious than it is on the web UI (even on handhelds), and so it seems more important to allow the user to choose *exactly* what to display. Anyhow, my original complaint (that Fishbone was displaying something inappropriate) was user error. Do we want to close this out, or is there a change that's really appropriate?
leaving open for now, but targetting for 7.0 so it can be reviewed in case there are any changes to the titleformatting ui desired.
From bug 6040, a suggestion for the Player settings of the title format in the web interface. I think this would eliminate a little of the confusion. > This pref is both awkward to explain and awkward to use, as you can only > add one at a time here. I'm not sure why you don't just make all of > them selectable at the player. I can't imagine people changing these > very often from the remote ui, so whether there are 3 or 15 choices at > the player should make little difference. It would simplify this pref > a lot, and make it much easier to understand.
(In reply to comment #5) > It's probably much simpler to just get rid of both lists in favour of a single > pref for server and player. If you mean for each having a single Title Format string definable only in the web interface and no longer having the player format selectable from a list in the remote ui, I agree. Just set some defaults (different for the server and for new players) and allow them to be edited. I don't really understand the need to be able to change it from the remote and can't imagine anyone uses it that often. It's not like changing brightness or text size - it takes quite a few button presses to accomplish.
Given the availability of the MusicInfo Screensaver plugin, it makes sense to change the server setting to a simple pulldown to select the current format from the defaults. The player setting can then also be a single pulldown to select the current format for players. No harm in keeping the INPUT.Choice settings on player UI as this would match the web UI player setting. This should mean we can clear this off as well as bug 6040
Created attachment 2438 [details] rough patch this does as I have described. The fixed default set are now available as Slim::Utils::Prefs::titleFormats (similar to the dateformats we have in Slim::Utils::DateTime). The web and player settings are simplified to just a pulldown. Player UI uses checkbox UI from the same list.
oh, I did not redefine strings for the above. obviously the bits about adding new formats should be removed. Instead just explain what the format blocks mean. This can be reduced to the same string rather than two large blocks. All you need are two new strings to say "This affects player display" "This affects web interface" to tack onto the end of the longer description. Good news to have less to translate :)
Created attachment 2439 [details] more tweaks just a few added tweaks beyond the first patch to fix how the prefs are pulled for ui handling.
could it be that the last commits created new problems with reading title format prefs in the Players section? i installed the 04-dec nightly and with this version i can't save the player Title Format in the webinterface. i tried changing the format number in server.prefs directly, but unfortunately this doesnt seem to affect the string sent to the player at this time.
This is a snip of my log for current build: [07-12-04 21:14:56.6895] Slim::Utils::Prefs::Base::set (114) setting server::titleFormat to [ "TITLE", "DISC-TRACKNUM. TITLE", "TRACKNUM. TITLE", "TRACKNUM. ARTIST - TITLE", "TRACKNUM. TITLE (ARTIST)", "TRACKNUM. TITLE - ARTIST - ALBUM", "FILE.EXT", "TRACKNUM. TITLE from ALBUM by ARTIST", "TITLE (ARTIST)", "ARTIST - TITLE", "TRACKNUM. ARTIST - TITLE (TRACKSTATRATINGDYNAMIC)", "TRACKNUM. TITLE (TRACKSTATRATINGDYNAMIC)", "PLAYING (X_OF_Y) (TRACKSTATRATINGSTATIC)", "PLAYING (X_OF_Y) TRACKSTATRATINGSTATIC", "TRACKSTATRATINGNUMBER", ] [07-12-04 21:14:56.7957] Slim::Utils::Prefs::Base::set (114) setting server::titleFormatWeb to 2 The setting of array prefs were recently changed, but this was to help with a known issue that prevented saving. Caching could explain if this were not behaving as above. Please clear the browser cache. set prefs to DEBUG for a comparable log. Other tweaks mentioned above have not been merged with svn yet.
Dean, any chance on some feedback here since this does affect the UI? See comments 10-13 specifically for the details of the proposed patch. Let me know if there are other elements you think should be included.
I think a single list of available formats that is available for selection for the web or player UI is reasonable.
in trunk at change 15415 to let folks have a look. Those wishing to have extended options will probably prefer the MusicInfo Screensaver.
I'm not so glad about this change: even MIS was relying on the server settings/title formats to get the list of available formats. Now there's no way to actually add format strings. Only lists to choose them from. This means whoever is not happy with the preset, must install a 3rd party plugin, even if it's only as simple a change as "TITLE - ALBUM". Oh, and that plugin still has to be written/enhanced to be able to do this.
(In reply to comment #19) > This means whoever is not happy with the preset, must install > a 3rd party plugin, even if it's only as simple a change as > "TITLE - ALBUM". Oh, and that plugin still has to be > written/enhanced to be able to do this. I'll ask once again: Why is there a need for a selectable list? Why not simply have a text input box to define the title format string in both the server and player settings? Then the user can define whatever format they like using the available data elements. What's lost is not the flexibility to define the format, but simply to be able to change the format through the remote ui. The gain in making this change would be to great simplify the option on both the server and player sides in the web ui.
> I'll ask once again: Why is there a need for a selectable list? Why not simply > have a text input box to define the title format string in both the server and > player settings? If you don't want the user to manually edit the format string whenver he needs to define a format string, we need some means to store those presets. A simple text box would require to eg. enter the same format string over and over again if you had more than one player.
I'm confused. Is this resolved?
No, it's not resolved. kdf removed the editing part of title formats, as he thought 3rd party plugins such as MusicInfoSCR could be used by those who wished that amount of flexibility. But that plugin doesn't handle this at all, is relying on SC to do this. Thus he reverted that change if I'm no wrong (or didn't merge the change in the Ray branch with trunk). We'll have to take a decision what way we want to go. If we want to get rid of this functionality in SC, then I'll need some time to fix my plugin ;-)
Let's leave this as it was and have Brian review the UI for 7.1.
will do....
Speaking only as the submitter, and not as somebody who's particularly familiar with the guts of the software... This was resolved for me within the first day or so, when KDF pointed out that I was tweaking the wrong control.
given we're nearing 7.1, is there a conclusion here or should it be closed as resolved (as it is for the reporter) and leave it at that?
Let's close it and reopen other more specific bugs as appropriate.
This bug has now been fixed in the 7.1 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC