Are you talking about the scanner which does the music inventory or the song scanner which allows you to ffwd/rwd within a song?

The song scanner which does ffwd/rew.

It shows current position and total size using the mm:ss format.  I'm suggesting it should use the same format as the now playing position information.

Alan - is this something obvious in the song scanner code?

SongScanner users the following hard-wired format statement:

sprintf("%01d:%02d / %01d:%02d", $pos / 60, $pos % 60, $dur / 60, $dur % 60);

What would be better?

Dean says we should use hours if they're there.  Michael asks this be assigned to him.

For SB3, its pretty easy, although not tested except on SB3. Change so SongScanner/Plugin.pm

85c85,97
< 		    return sprintf("%01d:%02d / %01d:%02d", $pos / 60, $pos % 60, $dur / 60, $dur % 60);
---
> 			my $durpos;
> 			if (int($pos / 3600) > 0) {
> 			    $durpos = sprintf("%01d:%02d:%02d / ", $pos / 3600, ($pos % 3600) / 60, $pos % 60);
> 			} else {
> 			    $durpos = sprintf("%01d:%02d / ", $pos / 60, $pos % 60);
> 			}
> 			if (int($dur / 3600) > 0) {
> 			    $durpos = $durpos . sprintf("%01d:%02d:%02d", $dur / 3600, ($dur % 3600) / 60, $dur % 60);
> 			} else {
> 			    $durpos = $durpos . sprintf("%01d:%02d", $dur / 60, $dur % 60);
> 			}
> 
> 			return $durpos;

For the controller, its harder.  Its easy to make the same change to the strings:

in Scanner.lua

--- Scanner.lua.orig	1969-12-31 19:00:00.000000000 -0500
+++ Scanner.lua	2009-01-05 17:17:23.000000000 -0500
@@ -48,9 +48,12 @@
 module(..., oo.class)
 
 local function _secondsToString(seconds)
-	local min = math.floor(seconds / 60)
-	local sec = math.floor(seconds - (min*60))
-
+	local hour = math.floor(seconds / 3600 )
+	local min = math.floor((seconds / 60) - (hour*60))
+	local sec = math.floor(seconds - (min*60) - (hour*3600))
+	if hour > 0 then
+		return string.format("%d:%02d:%02d", hour, min, sec)
+	end
 	return string.format("%d:%02d", min, sec)
 end


but this messes up the spacing in the scanner widget, and I don't know how to fix that.  The field sizes for the times have to be larger by at least one character - one will do for up to 9 hours if I understand what I'm doing at all.

Michael: please target appropriately

Created attachment 4575 [details]
diffs of changes probably not in right patch form

I've hacked both.  You will want whomever is responsible for the controller
skin to take a look at the tradeoff I made.  I don't see how to right pad only
the elapsed text so I'm wasting a bit of room on the right of the remain
text since both are right padded.

Also - another anomaly I did not change/fix is that the SC SongScanner displays
elapsed/total while the controller scanner displays elapsed / remain time.  If
you want to make them the same you need to choose and than make the obvious
change in the computation.

One other caveat - I'm not a perl programmer so please look at my perl and see if it's clean.  In particular, the int(.. in the if statement is needed to make it work and I don't understand why - but I don't understand perl type notation :-(

Thanks for the patch! Will test it.

Ben - would you mind taking a look at the SP part of this?

change 24598 - fix time format on SB display

change 3747 - fix time display on SqueezePlay

Thanks for your patch!

One question remains though: while we now have the same hh::mm::s display (if needed), SP uses playtime/remaining, while SC uses playtime/totaltime. Which one should we use?...

change 24601 - use playtime/remaining on the player UI too

Feel free to open a new bug if you don't like it :-)

Created attachment 4609 [details]
better fix for contoller

Michael - I'm sorry I'm so slow - old age maybe.  Sigh.  In any case, I finally groked the way the scannerGroup widget works, and know how to format it so both times stay close to the scanner bar no matter what size they are.  New diff is attached.

Michael: Can you check out Marc's attached patch.

May latest suggestion was just polish.  And it's different from the now playing progress bar, in that it keeps both values a constant distance from the slider, no matter the size of the values.  

My initial patch kept the elapsed a constant distance away, but not remain.  The now playing does it the other way.  It keeps remain a constant distance and elapsed not.  I'm sorry it took me so long to figure out how to make this stuff work and what it was doing.

If you guys care about this, tell me how you want it to work and I'll post the right patch.  But now playing is too complicated for me to mess with, so I'm not suggesting changing that.

If you want, I can make the scanner look the same as now playing.

Marc - I don't see any difference in the two patches for SqueezePlay. What line did you change?

Boy I must be a PITA.  Looks like up uploaded the wrong diff the second time.

Before a upload anything, please consider the issues I raised in my last post.  This is now just about details of the layout, and I can't really decide for you.  To repeat, the bar has elapsed - slider - remain.

The choices are:

elapsed and remain both left aligned - so elapsed has a variable space between it and slider as it's size changes.  This is how the current bars work.

elapsed and remain both right aligned - so remain has a variable space.  This is how the patch I dropped works.

elapsed right aligned, remain left aligned - which I think is prettier but doesn't match the now playing progress display.

(given how unimportant this is, if I were you I'd probably leave it alone, or ask me to make it consistent with the way it was).

Verified fixed in

SqueezeCenter 7.3.3 r26407
Controller 7.3 r5577

This bug has been fixed in the 7.3.3 release version of SqueezeCenter!

If you haven't already. please download the new version from http://www.logitechsqueezebox.com/support/download-squeezecenter.html 

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.