Jukebox should safely ignore when referenced media is not found

[manuq]

And may also tell the user: "N medias were not found".

TestCase:

1. start Jukebox from scratch
2. add media from a external device, like a pendrive
3. stop the activity
4. remove the external device, restart the activity from the Journal entry

Currently, a OSError raised, can be seen in the logs for the second time the activity is started. Complete log attached.

Traceback (most recent call last):
36	  File "/home/olpc/Activities/Jukebox.activity/jukeboxactivity.py", line 491, in _start
37	    jobject = datastore.get(url[len("journal://"):])
38	  File "/usr/lib/python2.7/site-packages/sugar/datastore/datastore.py", line 295, in get
39	    return RawObject(object_id)
40	  File "/usr/lib/python2.7/site-packages/sugar/datastore/datastore.py", line 228, in __init__
41	    stat = os.stat(file_path)
42	OSError: [Errno 2] No such file or directory: '/run/media/olpc/9DF7-AE82/test-files/Hydrate-Kenny_Beltrey.ogg'

[erikos]

Moving out after discussion with Manu.

[godiard]

The attached patch show a alert, if the media to be played is not found. The control is done in the different interactions the user can do (in the playlist, or with the buttons in the toolbar)

The playlist is preserved.

[manuq]

The testcase, starting Jukebox from scratch, succeeds. But I've found a regression:

Plug a stick with an ogg inside, go to the Journal, click on the stick icon, click on the ogg. It starts Jukebox but doesn't play the ogg, it displays an error message.

[manuq]

Screenshot of the regression

[godiard]

Thanks Manu.

Here I upload a new version of the patch.

[humitos]

I tested the two things involved in this ticket with the patch that gonzalo sent and they work properly.

There is something that I don't like and it's related with the message error; it says:

Error: The file /run/media/olpc/HUMITOS/words2.ogg was not found

I think that is not a good message for a child, I would change it by something like:

Error: The file words2.ogg was not found. Please, insert the stick / volume (or something like that -English speakers required here) named HUMITOS to play this file

... or something like that. I mean, I would like to show a useful message for a child

[garycmartin]

What happens if there are multiple tracks missing (I'm assuming a kid might keep a music/video collection on a USB memory stick and have many)? I assume it is also possible that this message will be generated if the user erases tracks from their Journal and then tries to resume a Jukebox playlist referencing it? Multiple missing tracks could be from multiple devices and/or the Journal.

Personally I would avoid using the word Error. Manuq, I think, was close in his original ticket description. For the case when more than one track is missing perhaps something like:

N tracks not found.

Another (more complicated) option could be to list the first few missing track names to provide more information:

Tracks words1.ogg, words2.ogg, words3.ogg and N others not found.

If only one track is missing we can be more informative:

Track words2.ogg from HUMITOS not found.

Or if the missing item was from the Journal:

Track words3.ogg from Journal not found.

I guess it might have been easier to just disable/grey out missing tracks in the playlist ;)

[godiard]

Replying to humitos:

Thanks by the comments.

Please do a test of other use cases, not only this one. I want to know if I broken anything more

[godiard]

Replying to garycmartin:

What happens if there are multiple tracks missing (I'm assuming a kid might keep a music/video collection on a USB memory stick and have many)? I assume it is also possible that this message will be generated if the user erases tracks from their Journal and then tries to resume a Jukebox playlist referencing it? Multiple missing tracks could be from multiple devices and/or the Journal.

The test is done when the media is played. Will be one message by media.

Personally I would avoid using the word Error. Manuq, I think, was close in his original ticket description. For the case when more than one track is missing perhaps something like:

N tracks not found.

Ok.

Another (more complicated) option could be to list the first few missing track names to provide more information:

Tracks words1.ogg, words2.ogg, words3.ogg and N others not found.

If only one track is missing we can be more informative:

Track words2.ogg from HUMITOS not found.

Or if the missing item was from the Journal:

Track words3.ogg from Journal not found.

I prefer go for the non complicate route :)

Personally, I am not sure "Track words2.ogg from HUMITOS not found." is a good message. What is HUMITOS? And the logic to know this is a path pointing to a non munted device can be tricky (now are in /run/media/olpc/ but in older versions were in /media). We already are showing the path in the mounted device palette. Is not nice, but is information needed.

I guess it might have been easier to just disable/grey out missing tracks in the playlist ;)

Disable and don't show a message? And the user should guess what happened?

[humitos]

Replying to godiard:

I prefer go for the non complicate route :)

What's is the way that you prefer? The: "N tracks not found."?

Personally, I am not sure "Track words2.ogg from HUMITOS not found." is a good message. What is HUMITOS? And the logic to know this is a path pointing to a non munted device can be tricky (now are in /run/media/olpc/ but in older versions were in /media). We already are showing the path in the mounted device palette. Is not nice, but is information needed.

"HUMITOS" is the volume label of the Stick and is given by the dbus (or GIO) API. It's something that Sugar itself already known. I mean, Sugar shows the volume label on the palette.

I guess it might have been easier to just disable/grey out missing tracks in the playlist ;)

Disable and don't show a message? And the user should guess what happened?

I think we should show a message here AND disable the tracks that can't be played. Going on this way will show a good explanation message and will show a good GUI that reflects the message shown

[godiard]

Replying to humitos:

Replying to godiard:

I prefer go for the non complicate route :)

What's is the way that you prefer? The: "N tracks not found."?

No, show one message by media.

Personally, I am not sure "Track words2.ogg from HUMITOS not found." is a good message. What is HUMITOS? And the logic to know this is a path pointing to a non munted device can be tricky (now are in /run/media/olpc/ but in older versions were in /media). We already are showing the path in the mounted device palette. Is not nice, but is information needed.

"HUMITOS" is the volume label of the Stick and is given by the dbus (or GIO) API. It's something that Sugar itself already known. I mean, Sugar shows the volume label on the palette.

I know that, but will the user understand it? If we do this, will need:

• Check if the path is in one of the directories use to mount devices ('/mnt', '/media', '/run/media/$USER/') and keep the remaining part in the path.

• If there are any error show the path.

• If is not in any of this directories show the path.

• If the media was in the journal will have a file name as 3ae5362afe6af66aae23a366, what we should show in that case?

• Any other case?

I guess it might have been easier to just disable/grey out missing tracks in the playlist ;)

Disable and don't show a message? And the user should guess what happened?

I think we should show a message here AND disable the tracks that can't be played. Going on this way will show a good explanation message and will show a good GUI that reflects the message shown

I have not tried disable elements in a listview, but if is possible, we can do it in the process where we try to get the title with the metadata.

I think we can do another patch with the message changes, if there are not other objections about the patch, I will push it.

[manuq]

Discussing with Gonzalo we came to this. Gary, what do you think?:

1. a message is shown at the start "N tracks not found" with a "Details" button
2. the Details button displays a list of paths that were not found
3. the rows of the tracks that were not found are grayed out

As the list of paths can't fit in the Sugar Alert, they can be displayed in the canvas. Jukebox is also displaying another message there attachment:Screenshot%20of%20_Jukebox%20Activity_.png:ticket:1548

[manuq]

This is the image I wanted to show above:

 http://bugs.sugarlabs.org/attachment/ticket/1548/Screenshot%20of%20_Jukebox%20Activity_.png

[godiard]

Requested feedback to the design team, when we have it, this is a task for humitos.

[garycmartin]

Replying to manuq:

Discussing with Gonzalo we came to this. Gary, what do you think?:

1. a message is shown at the start "N tracks not found" with a "Details" button

Yes, that's nice and clear.

2. the Details button displays a list of paths that were not found

OK, yes this is one way – we need to make sure this list display is reasonably set out on the canvas (line wrapped, some padding around the edge of the screen, allow the list area to scroll if there are many missing tracks etc).

One alternative that might be simpler, for each greyed out track add a small error (!) icon badge, hovering/clicking on the badge reveals a palette with the full missing path.

3. the rows of the tracks that were not found are grayed out

As the list of paths can't fit in the Sugar Alert, they can be displayed in the canvas. Jukebox is also displaying another message there attachment:Screenshot%20of%20_Jukebox%20Activity_.png:ticket:1548

Oh wow, yes that one is rather ugly! ;) Can we clean that one up? Centre the message, plenty of padding either side of the text, line wrap if necessary, remove the technical jargon/code, perhaps put an error icon above the text. A design much like the other message designs as in #3714  http://bugs.sugarlabs.org/attachment/ticket/3714/Jukebox_playlist_informational_only.png

[manuq]

Replying to garycmartin:

Replying to manuq:

2. the Details button displays a list of paths that were not found

OK, yes this is one way – we need to make sure this list display is reasonably set out on the canvas (line wrapped, some padding around the edge of the screen, allow the list area to scroll if there are many missing tracks etc).

One alternative that might be simpler, for each greyed out track add a small error (!) icon badge, hovering/clicking on the badge reveals a palette with the full missing path.

+1 for the simpler (!) icon badge, and the hovering.

3. the rows of the tracks that were not found are grayed out

As the list of paths can't fit in the Sugar Alert, they can be displayed in the canvas. Jukebox is also displaying another message there attachment:Screenshot%20of%20_Jukebox%20Activity_.png:ticket:1548

Oh wow, yes that one is rather ugly! ;)

I knew you were going to like it :)

[humitos]

Show an alert at startup if there is missing tracks and show full paths in the canvas

[humitos]

Screenshot after aplying the patch

[godiard]

Applied as 38a452d9352ebe92233eb328a53b2b82a76a02a7.

Additionally, I close the alert / panel error when a device is mounted/unmounted, before the playlist is rescaned.