mp3 support for Uruguay

[cjb]

Uruguay's current build includes the eToys mp3 player support. They'd like to upgrade to 8.2.0, but at the moment they'd lose this audio playback if they did that. This is a request on their behalf for a way to have a recent build of eToys and the mp3 player installed.

OLPC continues not to want to distribute the MP3 player plugin.

[bert]

Could someone describe how the kids are actually using Etoys to play mp3s (from USB drives?), and what the learning objective is in that?

Also, the question is how exactly that new version would be published. Technically one could simply move /usr/lib/squeak/3.x/MPEGPlugin from an old Squeak installation to the new one.

[cjb]

Bert, I think the kids are downloading MP3s (somehow) from the net, and Uruguay's happy with that and don't want it to become unavailable. I think having it remain available is a request from their tech team (who don't want a lot of support calls asking how to play music) rather than their learning team, though.

If it does work to just do the mv, that's great and they can handle the rest all themselves. Emiliano, maybe you could test moving /usr/lib/squeak/3.x/MPEGPlugin from your 656 build over to 8.2 and see if mp3 playing still works?

[mchua]

|Test case|

On an XO running Uruguay's current build,

1. Download an mp3 file (see http://www.google.com/search?hl=en&q=mp3%20samples) and play it in EToys. You should hear the mp3.
2. upgrade to 8.2.0 (see http://wiki.laptop.org/go/Release_notes/8.2.0#Upgrading_from_previous_releases)
3. Play the mp3 file again in EToys. It should still work and you should still hear the mp3 playing.

I am unclear on how one plays an mp3 file in Etoys - can someone provide instructions or a pointer so that any tester can pick this up and try it when the build is ready? (Thanks!)

[ohshima]

Replying to mchua:

|Test case| I am unclear on how one plays an mp3 file in Etoys - can someone provide instructions or a pointer so that any tester can pick this up and try it when the build is ready? (Thanks!)

I can't remember if it was possible to open from Journal in the past, but it seems that you need to go through the following steps:

On an installation with the codec and binding (called Mpeg3Plugin) in the VM, start Etoys, click on the tresure box on the gray bar, drag out the "Object Catalog" (or "Catálogo de Objetos"). Then, click on the Multimedia button, and drag out "MPEGPlayer" (or "Reproductor MPEG"). Click on "Open" (or "Abrir"), and navigate to the .mp3 file in the file system, and click on "accept" (or aceptar).

[ohshima]

And it is probably worth to mention that on a Gnome, Windows, Mac, and etc., you can drag a .mp3 file from Nautilus, Explorer and Finder or something like that to the running Etoys session. As the same binary runs on a regular Fedora, testing it there would help to make quick turn around during a test.

[cjb]

Hi,

Replying to ohshima:

I can't remember if it was possible to open from Journal in the past, but it seems that you need to go through the following steps:

Yes, it was possible. The workflow in Uruguay is to get an mp3 into the journal, and then clicking Resume on it automatically launches eToys (which registered that mimetype) and starts playback.

[bert]

Replying to cjb:

The workflow in Uruguay is to get an mp3 into the journal, and then clicking Resume on it automatically launches eToys (which registered that mimetype) and starts playback.

I see. Yes, that code path ("resuming" a media file) simply creates a new project and drops the file in (using the same logic as in drag-and-drop).

This use case was not really anticipated, we usually think of Etoys as an authoring tool. When used as media player or image viewer, pressing the stop button should not really save an Etoys project. Do the kids work around this, or does the Journal simply fill up with useless projects?

If we want to better support this usage we could add a "play and quit" option to the menu (try resuming/dropping an mp3 to see the menu), we could also alter the exit logic to not save when the project is empty or has just a single unscripted media player in it. Comments?

I wonder how we could help the kids make their experience much better. For example, it's pretty trivial with a little piece of Squeak code to grab all the mp3s in the Journal and play them back. If we could make it as simple to build a media player using Etoys tiles that would be awesome. E.g., based around a "JournalMorph" that would list the journal entries of a given mime type? Ideas?

[mstone-xmlrpc]

Pushing out to 9.1.0, per edmcnierney's request.

[mstone]

Bert -- sorry for the noise on this ticket; I didn't think to tag the tickets that were supposed to remain in 8.2.1 before mass-moving the rest.

[edmcnierney]

A conversation with mstone clarified my questions. It appears that the current MP3 plugin was shipped by OLPC unintentionally in build 656. It was removed from 8.2 as a result, and Uruguay considers this a regression and would like it restored. OLPC does not intend to restore the plugin to our standard system image.

Uruguay is able to add this plugin themselves as one part of the customizations they intend to perform on our 8.2 release before deploying it. OLPC is assisting Uruguay in creating a signature for their customized image so they may more easily distribute and use it.

If Uruguay were to be provided with this plugin by the etoys development team, along with any necessary instructions to add it to their customized build, they would be able to distribute it and this ticket could be resolved.

[garycmartin]

Replying to cjb:

Hi, Replying to ohshima:

I can't remember if it was possible to open from Journal in the past, but it seems that you need to go through the following steps:

Yes, it was possible. The workflow in Uruguay is to get an mp3 into the journal, and then clicking Resume on it automatically launches eToys (which registered that mimetype) and starts playback.

So did Uruguay also customise their /usr/share/sugar/data/mime.defaults file to add the mp3 MIME type pointing to EToys? As a tester it's hard to realistically test this case as it's not clear what customisations were made (i.e in this case where can I download the MP3 plugin, and did they make changes to the default MIME file), or what additional changes they'll make to an 8.2 image.

Perhaps we should be suggesting they install http://wiki.laptop.org/go/Jukebox and point them to an mp3 gstreamer plugin as the customisation solution (seems like EToys is a really poor use case as a media player that could be eating cpu and nand space).

[bert]

Replying to garycmartin:

So did Uruguay also customise their /usr/share/sugar/data/mime.defaults file to add the mp3 MIME type pointing to EToys? As a tester it's hard to realistically test this case as it's not clear what customisations were made (i.e in this case where can I download the MP3 plugin, and did they make changes to the default MIME file), or what additional changes they'll make to an 8.2 image.

No, when the system still provided the mpeg plugin, the Etoys activity bundle simply declared to handle mp3 files. We removed that declaration when OLPC asked us to remove the plugin.

To re-add that support the activity would have to declare it again, but it would only work if in fact the plugin is available. So here is a thought:

Instead of adding the plugin to the system image, make an Etoys activity bundle that contains both the plugin and the declaration to handle mp3. That way we would not need a new rpm and also we would avoid the case that the bundle declares mp3 support without the plugin actually being installed.

[mchua]

Consensus from today's 8.2.1 meeting: The Etoys-with-mp3 .xo bundle should be outside 8.2.1 official, but should be one of Uruguay's customizations that they roll up into a build for OLPC to sign.

[bert]

Etoys activity bundle with MP3 support

[bert]

Attached a bundle that if installed in 8.2 allows to play MP3s from Journal in Etoys - tested by manually copying an mp3 into the datastore (playing from USB should work, too):

copy-to-journal -m audio/mpeg some.mp3

However, when you click an MP3 in Browse, it is grabbed by the browser's Totem plugin which claims to be able to play audio/mpeg (even though it cannot in a regular 8.2 install). To verify, type "about:plugins" in Browse's address bar.

Reassigning to Ed. Cannot do much more until someone bothers to answer my questions above.

[bert]

Even with the totem plugin removed I am unable to download mp3 files to the Journal. I get a "download window" instead that downloads to the file system, not the datastore.

[bert]

Replying to bert:

Even with the totem plugin removed I am unable to download mp3 files to the Journal. I get a "download window" instead that downloads to the file system, not the datastore.

After disabling rainbow I cannot reproduce this problem anymore, even when enabling security again.

However I noticed there are more MIME types for MP3s in use - the bundle for now only accepts audio/mpeg but I have seen audio/x-mp3 too, and there may be even more.

All in all I think the best solution would be to simply add the GStreamer FFmpeg plugin which would enable Totem to play back the files it claims to support.

[erikos]

This is really strange. I did install 767 and saw the issue once - but nothing in the logs that would help me to diagnose. So I enabled debug logs and restart sugar - then I could not see the error any more. Bert did try to disable rainbow - but that did not give us reproducible conditions neither.

I flashed the machine another time to check if it was an init problem or something like that - but i could not reproduce the issue then at all (i enabled debug logs before trying though).

I am a bit puzzled.

[cscott]

Changed status to 'diagnose', since it seems there is an unresolved bug.

[bert]

Replying to cscott:

Changed status to 'diagnose', since it seems there is an unresolved bug.

I'd not worry about the bug but rather suggest to Uruguay to install the GStreamer mpeg plugin. This is how the system has been designed, it will allow the kids to directly play MP3s instead of abusing Etoys for that purpose, littering the Journal etc.

[cjb]

dsd points out that we use an old backported gstreamer in 8.2.1, so "just install gstreamer-ffmpeg from freshrpms" might not work.

[dsd]

Yes, the F9 gstreamer-ffmpeg RPM from freshrpms fails with dependency errors because of the above.

The F7 one installs but it does not work. gstreamer complains that there is no decoder installed to handle the file.

[dsd]

I think gstreamer-plugins-ugly is needed (perhaps in addition to gstreamer-ffmpeg). I tried the one from freshrpms F7 repos but it fails:

-> Finished Dependency Resolution gstreamer-plugins-ugly-0.10.8-1.fc9.i386 from freshrpms has depsolving problems

--> Missing Dependency: libgstrtsp-0.10.so.0 is needed by package gstreamer-plugins-ugly-0.10.8-1.fc9.i386 (freshrpms)

gstreamer-plugins-ugly-0.10.8-1.fc9.i386 from freshrpms has depsolving problems

--> Missing Dependency: gstreamer >= 0.10.14 is needed by package gstreamer-plugins-ugly-0.10.8-1.fc9.i386 (freshrpms)

gstreamer-plugins-ugly-0.10.8-1.fc9.i386 from freshrpms has depsolving problems

--> Missing Dependency: libgstsdp-0.10.so.0 is needed by package gstreamer-plugins-ugly-0.10.8-1.fc9.i386 (freshrpms)

Error: Missing Dependency: libgstrtsp-0.10.so.0 is needed by package gstreamer-plugins-ugly-0.10.8-1.fc9.i386 (freshrpms) Error: Missing Dependency: gstreamer >= 0.10.14 is needed by package gstreamer-plugins-ugly-0.10.8-1.fc9.i386 (freshrpms) Error: Missing Dependency: libgstsdp-0.10.so.0 is needed by package gstreamer-plugins-ugly-0.10.8-1.fc9.i386 (freshrpms)

I think there is no quick solution to this "bug"

[dsd]

OK. Found a solution. In the above, it was actually using fedora 9 above. gstreamer-ffmpeg is not needed. Here's what I did:

• installed http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/9/freshrpms-release/freshrpms-release-1.1-1.fc.noarch.rpm
• installed ftp://194.199.20.114/linux/fedora/updates/7/i386/libdvdread-0.9.7-3.fc7.i386.rpm
• modified /etc/yum.repos.d/freshrpms to use "7" rather than "$releasever"
• yum install gstreamer-plugins-ugly

Now, in browse, the totem browser plugin opens up when you clikc on an MP3, then you can click the play button to listen.

MP3s cannot be opened from the journal though. It does not know which activity to launch.

[dsd]

To fix the journal problem, you can add the audio/mpeg mime type to /home/olpc/Activities/Browse.activity/activity/activity.info and restart sugar.

I think this is a suitable workaround for uruguay. This is all a bit messy, but that's the price of an unsupported feature :)

[bert]

Great! Thanks.

[skierpage]

Replying to dsd:

* three installs

For individual end-users, it might be simpler to install the Fluendo MP3 codec; I updated http://wiki.laptop.org/go/Fluendo_mp3_decoder

[cjl]

Does Uruguay have it's mp3 solution yet? Can this 15 month old ticket be closed?

[Quozl]

Bernie's recent work for Paraguay adds mp3 support to os140py, per patch 671b043 in repository git://git.paraguayeduca.org/users/bernie/olpc-os-builder.git ... by adding package gstreamer-plugins-ugly. This is not a build by OLPC.

Based on the availability of a straightforward solution for use in current deployment-customised builds, I'm happy to close this ticket.