Bug 12689 - Podcast handling should be revised
: Podcast handling should be revised
Status: RESOLVED DUPLICATE of bug 11502
Product: SqueezePlay
Classification: Unclassified
Component: Browser
: unspecified
: PC Windows XP
: P4 normal (vote)
: ---
Assigned To: Unassigned bug - please assign me!
:
Depends on: 13179
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-05 22:59 UTC by Caleb Crome
Modified: 2009-10-07 10:03 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Caleb Crome 2009-07-05 22:59:35 UTC
When I enter podcasts, the 'play by pressing item' is not the right behavior.  

It's very difficult (nearly impossible if you don't read some manual) to read the podcast description, especially without playing the thing.  I want to read the description of a podcast that I'm not listening to.  On Boom, I can easily do that.  And when I do finally get to the descirption, it's a 1-liner.  

For podcasts, I need to be able to read the whole description, as a multiline text, with manual up-down scrolling. It's not okay to have a 1-line, auto-scroll of the description -- that's completely useless since podcasts descriptions can be very long.  It's also not usable because the clock screensaver pops up and disrupts the auto-scroll-one-line-description.

At the least, I should be able to click the description line to get a full text multi line description.
Comment 1 Philip Meyer 2009-07-11 03:49:04 UTC
I agree.  Podcast descriptions are also often multi-line (eg. containing a track listing), and would benefit from display on the LCD screen as a text area.

But I also feel that this extends to normal songs too - the song information page gives access to comments and other useful information, so access to that information (especially for the currently playing track) is also now very awkward.  There has been talk about extending song information to include extra artwork, lyrics, biography, album reviews, etc, by scanning extra song tag metadata, or from other sources (internet, local files, etc).
Comment 2 Ben Klaas 2009-07-16 09:09:17 UTC
changing several bugs at once-- target milestone on these do not apply to the CXR/CAT milestone
Comment 3 Ben Klaas 2009-08-26 07:49:28 UTC
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
Comment 4 Ben Klaas 2009-10-01 15:06:17 UTC
I think this is not correctly assigned to me...

my personal opinion is that our podcast support needs a full review and well-thought out redesign. That would be 8.0ish time frame I think

untargetting, adding bug_meeting flag for discussion.
Comment 5 James Richardson 2009-10-07 10:03:38 UTC
*** This bug has been marked as a duplicate of bug 11502 ***