Ticket #8982 (closed defect: fixed)

Opened 6 years ago

Last modified 4 years ago

mp3 support for Uruguay

Reported by: cjb Owned by: edmcnierney
Priority: normal Milestone: 8.2.1
Component: browse-activity Version: not specified
Keywords: sound cjbfor9.1.0 8.2.1:+ Cc: epastorino, reuben, edmcnierney, etoys, garycmartin, mchua, tomeu, erikos
Action Needed: finalize Verified: no
Deployments affected: Uruguay Blocked By:
Blocking:

Description

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.

Attachments

Etoys+MP3-94.xo (115.6 kB) - added by bert 6 years ago.
Etoys activity bundle with MP3 support

Change History

  Changed 6 years ago by cjb

  • cc epastorino, reuben added

  Changed 6 years ago by kimquirk

  • milestone changed from Not Triaged to 8.2.1

  Changed 6 years ago by 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.

  Changed 6 years ago by 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?

follow-up: ↓ 6   Changed 6 years ago by 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!)

in reply to: ↑ 5 ; follow-up: ↓ 8   Changed 6 years ago by 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).

  Changed 6 years ago by 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.

in reply to: ↑ 6 ; follow-ups: ↓ 9 ↓ 15   Changed 6 years ago by 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.

in reply to: ↑ 8   Changed 6 years ago by 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?

  Changed 6 years ago by bert

  • cc edmcnierney, etoys added
  • next_action changed from never set to communicate

  Changed 6 years ago by mstone-xmlrpc

  • keywords cjbfor9.1.0 added
  • milestone changed from 8.2.1 to 9.1.0

Pushing out to 9.1.0, per edmcnierney's request.

  Changed 6 years ago by mstone

  • milestone changed from 9.1.0 to 8.2.1

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.

  Changed 6 years ago by edmcnierney

  • next_action changed from communicate to package

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.

  Changed 6 years ago by edmcnierney

  • keywords 8.2.1:+ added

in reply to: ↑ 8 ; follow-up: ↓ 16   Changed 6 years ago by garycmartin

  • cc garycmartin added

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).

in reply to: ↑ 15   Changed 6 years ago by 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.

follow-up: ↓ 18   Changed 6 years ago by mchua

  • cc mchua added

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.

Changed 6 years ago by bert

Etoys activity bundle with MP3 support

in reply to: ↑ 17   Changed 6 years ago by bert

  • owner changed from etoys to edmcnierney
  • next_action changed from package to add to build

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.

follow-up: ↓ 20   Changed 6 years ago by bert

  • cc tomeu added

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.

in reply to: ↑ 19   Changed 6 years ago by bert

  • cc erikos added

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.

  Changed 6 years ago by 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.

follow-up: ↓ 23   Changed 6 years ago by cscott

  • next_action changed from add to build to diagnose

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

in reply to: ↑ 22   Changed 6 years ago by 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.

  Changed 6 years ago by 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.

  Changed 5 years ago by 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.

  Changed 5 years ago by 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"

follow-up: ↓ 31   Changed 5 years ago by 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:

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.

  Changed 5 years ago by dsd

  • next_action changed from diagnose to finalize

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 :)

  Changed 5 years ago by bert

  • component changed from etoys-activity to browse-activity

Great! Thanks.

  Changed 5 years ago by bert

  • summary changed from separate mp3 player package for etoys? to mp3 support for Uruguay

in reply to: ↑ 27   Changed 5 years ago by 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

  Changed 4 years ago by cjl

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

  Changed 4 years ago by Quozl

  • status changed from new to closed
  • resolution set to fixed

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.

Note: See TracTickets for help on using tickets.