Bug 330 - reloading Handheld skin can cause unexpected behavior
: reloading Handheld skin can cause unexpected behavior
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Skins
: 5.x or older
: All All
: P2 normal (vote)
: ---
Assigned To: Vidur Apparao
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-01 15:03 UTC by Kevin Pearsall
Modified: 2008-12-18 11:55 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments
place handheld skin inside a frame (50.97 KB, patch)
2005-01-29 19:46 UTC, KDF
Details | Diff
Refresh status automatically (1.95 KB, patch)
2005-04-22 05:22 UTC, Michael Herger
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Pearsall 2004-06-01 15:03:00 UTC
I have not had a chance to reproduce these yet, but I have had customers report the following:

- on the Status page, you can only click Next once, and pages after the first will not have that link.

- when refreshing the status page, since it does not automatically refresh, the currently playing song 
may jump back to whatever was playing when that initial status page was generated.

Reported on v5.1.5, one customer said he had problems with nightlies, of unknown date, and I have 
asked a couple of customers to try the latest (6/1/04) nightly.
Comment 1 Vidur Apparao 2004-06-04 09:22:11 UTC
I can't recreate the first problem, but I think I know what's going on with the
second. The URL of the status page contains the command parameters that got us
there (p0=playlist&p1=jump, for example). Refreshing the page reruns the
command. Maybe the status page should do an immediate META HTTP refresh to a
version without the command parameters?
Comment 2 Kevin Pearsall 2004-07-15 14:52:54 UTC
Ok, this first problem doesn't seem to happen any more.  I reproduced both of them but hadn't had a 
chance to update the bug...  The skipping a track thing when refreshing the page is pretty annoying 
though.
Comment 3 KDF 2005-01-22 04:50:49 UTC
having the whole page inside a dummy frameset would solve this problem.  Do any
handheld browsers have a problem with frames??
Comment 4 KDF 2005-01-29 19:46:57 UTC
Created attachment 261 [details]
place handheld skin inside a frame

This relieves the skin of the stated problems.	Where HandHeld skin is most
used, do those browsers have issues with frames??
Comment 5 Blackketter Dean 2005-03-11 14:08:31 UTC
Handheld skin is often used in browsers without frames.    A simpler solution would be to put a refresh 
button in the page itself.  (and have the auto-refresh load the base URL without the command 
parameters.)  Vidur says that it's not being automatically reloaded.  Vidur?
Comment 6 Michael Herger 2005-03-22 02:23:39 UTC
A refresh button on the page would IMHO be the same as the Status link in the top menu - that's what I'm 
using to refresh the display. And no, there's no automatic refresh.
Comment 7 Blackketter Dean 2005-04-20 13:10:24 UTC
Michael: how hard would it be to add an auto referesh of the status page that would reload without the 
parameters?
Comment 8 Michael Herger 2005-04-22 05:22:17 UTC
Created attachment 445 [details]
Refresh status automatically

Before I commit that patch I wanted to ask whether we should have some kind of
a redirect/refresh standard: status_header.html uses only a variable "refresh",
the url is hardcoded. I had to add the refresh to the pageheader.html - where I
don't want an url for only one page. Now I'm using a second variable for the
url in pageheader.html, which I have to create in status_header.html.

If we had a redirect hash (containing delay and url) in the params hash we
could add the (conditional) redirect directive to any pageheader.html - would
come in handy for my biography plugin, too ;-)
Comment 9 Blackketter Dean 2005-06-07 12:57:36 UTC
If this patch fixes the bug, then go ahead and commit it.  Feel free to submit another patch that cleans 
up the implementation.
Comment 10 Michael Herger 2005-06-07 14:51:49 UTC
I checked in change 3090 a few weeks back. IMHO this case can be closed.
Comment 11 Chris Owens 2008-03-11 11:27:51 UTC
This bug was marked resolved in Slimserver 6.1, which is several versions ago.  If you're still seeing this bug, please re-open it.  Thanks!
Comment 12 Chris Owens 2008-12-18 11:55:25 UTC
Routine bug db maintenance; removing old versions which cause confusion.  I apologize for the inconvenience.