The left hand pane is typically for browsing.  Right side top does update at a default rate of 30 seconds (reduced near end of track to try to change just after track change).  The playlist pane at the right side also reloads to the current track.

can you please clarify your request, and also change the summary to be more specific for later reference.

fishbone skin has an I icon next to each song in the playlist. you can always click on that.  Some skins open song info when you click on the title of the track in the 'now playing' section. Is that not acceptable?

Dean will have to comment on any automatic loading, as this would effectively break the ability to browse using the left pane (as mentioned above). Some UI issues would have to be resolved in order to avoid that conflict. 

How about adding a drop-down triangle to expand the Now Playing area on the right side with more detail?  

Of course, KDF has final say on his skin, but I think it makes sense to keep the now playing information together on the right.   

Since this is an enhancement request, it's going to need to be moved to 6.5.

Untargetting for post 6.5 assessment.

So it is an old wish/request... I hope the makers will modify the program. Much of MP3-players (Winamp, Windows Media Player, J. River Media Center, Vista Media Center) have the possibility. Otherwise the program becomes old-fashioned :-)

This might be a really nice enhancement.  Someone that has individual track art and/or extensive track comments or lyrics could have it all automatically displayed in the browse window while their music is being played.

I can think of a couple ways this might be implemented:

1. A button/link/checkbox/drop-down on the songinfo page that would enable an 'autoupdate' mode kept in a local javascript variable.  If a user is viewing a songinfo page, then they can turn on the autoupdate mode and whenever the now playing track changes the songinfo page is updated to reflect the current song.

2. A global pref to always have this autoupdate mode in effect.  Page updates would work the same as in #1.

3. A cookie that would keep the mode enabled for the user.  Set using the same web control as in #1.

Either way, since you can't interfere with library browsing, you'd only want the autoupdates to happen when the user is viewing the songinfo page.  So it would likely have to be the songinfo page itself that checks to see if autoupdate is enabled and then update itself to reflect the playing track.

*** Bug 8667 has been marked as a duplicate of this bug. ***

(In reply to comment #7)
> This might be a really nice enhancement.  Someone that has individual track art
> and/or extensive track comments or lyrics could have it all automatically
> displayed in the browse window while their music is being played.
> I can think of a couple ways this might be implemented:
> 1. A button/link/checkbox/drop-down on the songinfo page that would enable an
> 'autoupdate' mode kept in a local javascript variable.  If a user is viewing a
> songinfo page, then they can turn on the autoupdate mode and whenever the now
> playing track changes the songinfo page is updated to reflect the current song.
> 2. A global pref to always have this autoupdate mode in effect.  Page updates
> would work the same as in #1.
> 3. A cookie that would keep the mode enabled for the user.  Set using the same
> web control as in #1.
> Either way, since you can't interfere with library browsing, you'd only want
> the autoupdates to happen when the user is viewing the songinfo page.  So it
> would likely have to be the songinfo page itself that checks to see if
> autoupdate is enabled and then update itself to reflect the playing track.

This is exactly what I mean, but your English is something better :-)

I don't know how this forum works, but is there a possibility to see if this request will be granted or not?

Unassigned bugs cannot have a priority.