GNOME Bugzilla – Bug 561712
Support for Rock Box and its native Tag Cache DB
Last modified: 2009-07-30 00:15:50 UTC
I have created a plugin for Banshee which enables synchronisation with audio players using the Rock Box open source firmware. This plugin is designed to function in a similar way to the iPod plugin, by reading and writing Rock Box's native DB format.
Created attachment 123124 [details] The first version of the Rock Box Plugin Since I am not a commiter and my pluging consists of entirely new files, its not practiciale for me to produce a patch by hand. To use it extract the archive into the/src/Dap/ directory of a fresh SVN checkout. Then update /src/Dap/Makefile.am to build the new Banshee.Dap.RockBox directory. This is the first version and has two know problems. Firstly during a sync the existing metadata hash doesn't match so it always removes and addess all files at the moment. If your Rock Box device is an iPod currently you will need to disable the iPod plugin as it will pick up the device instead. Its also only been tested with the Rock Box 3.0 release and the latest Rock Box svn build.
Has any thought gone into creating a second plugin to convert existing players into RockBox devices?
(In reply to comment #2) > Has any thought gone into creating a second plugin to convert existing players > into RockBox devices? > You mean to install Rockbox on the device. The problem with that is there are lots of versions depending on which device you have. Also the device often needs its boot loader replaced. This is certainly true with the iPods, they have their boot loader changed to allow multi booting so you can boot apples iPod software or Rock Box. Rock Box has a very slick cross platform installer which handles all of this automatically. I think it would be difficult for us to recreate all that functionality. Its might be possible to make banshee download the latest version and start it for the user. With the iPod there are three ways of using it with Banshee. You can sync using the normal iPod extension (which means Apple's iPod software still works). The problem is you have to let Rock Box update its DB after each sync which takes several minutes. Also the tracks are stored in apples odd directory structure which makes it hard to manually find the tricks when the disk is mounted on a PC. You can use the Mass Storage extension and manually configure it to put the Tracks where you like on the device. This still requires a DB update after each sync which takes several minutes. It also takes several minutes of Banshee to show all the tracks when its inserted. This also menas you can't use Apple's iPod software If you use the extension attached then it copies the tracks to a Music folder on the devices where all the tracks are Stored in Atrist / Album / Track name subdirectories so its easy to find the tracks when the disk is mounted. It exports the Artwork in a format Rock Box is happy with. It reads Rock Box's DB so the tracks show up in a couple of seconds in Banshee. It also updates the DB so when any new tracks are added or removed they show up instantly in the DB. This does mean the tracks don't show up in the iPod software but since the Rock Box DB is just as capable for music at least its not such a big problem. Hope that helps.
(In reply to comment #1) Thanks for the patch ! You should be able to "svn add" the files you added (it's a local operation), and then "svn diff" would produce a proper patch. You also need to modify configure.ac so that the Makefile is generated. Please try to follow the coding guidelines from the HACKING file : indent with space, etc.
(In reply to comment #2) > Has any thought gone into creating a second plugin to convert existing players > into RockBox devices? > I don't think a Rockbox-Installer in Banshee would be a good idea. What could be done is an Updater, so everytime you connect a Rockbox Device the firmware does an update to the newest SVN or Stable Rockbox version (should be selectable)
(In reply to comment #4) > (In reply to comment #1) > Thanks for the patch ! > > You should be able to "svn add" the files you added (it's a local operation), > and then "svn diff" would produce a proper patch. > > You also need to modify configure.ac so that the Makefile is generated. > > Please try to follow the coding guidelines from the HACKING file : indent with > space, etc. > I will try to make an SVN patch for it. My only concern is I am not entirely sure about how to integrate it with the build system. I spent a while trying to get it to build via the projects Makefile. In the end I worked out I needed to add it to configure.ac and it seems to work. Its not optional like the other DAP extensions however and I am not sure about the Monodevelop Project files. I have been developing with C# for years but developing with Make is fairly new to me. The extension started out more as a proof of concept. I only read the contribution guidelines half way through when I realised it was actually useful and worth contributing back. So far I have concentrated on the technical side or things, like making sure it uses Banshee.IO. I will try and clean it up a bit more, but I am quite keen to solve the Meta Data Hash syncing bug first.
(In reply to comment #5) > (In reply to comment #2) > > Has any thought gone into creating a second plugin to convert existing players > > into RockBox devices? > > > > I don't think a Rockbox-Installer in Banshee would be a good idea. What could > be done is an Updater, so everytime you connect a Rockbox Device the firmware > does an update to the newest SVN or Stable Rockbox version (should be > selectable) > Yeah I agree especially as the official Rockbox installer is so good. In terms of updating it that sounds like it could be useful, although it does open up many of the same questions as making it install RockBox. There are lots of different builds of Rock Box so it would be important to make sure its installing the correct one. I think its certainly something worth considering.
I generally dislike the official installer but if one would not wish to directly implement a replacement maybe we could do a callout to the installer if it´s present and at least that way get rockbox installed
(In reply to comment #8) > I generally dislike the official installer but if one would not wish to > directly implement a replacement maybe we could do a callout to the installer > if it´s present and at least that way get rockbox installed > That is certainly what I would favour since installing Rock Box can be quite an involved process and complicated by the number of versions available for different devices. The only problem is how to best integrate the extension. Since the one in this bug is a DAP extension it only gets loaded when a device is offered to it and it accepts it. This prevents other DAP extensions devices from accepting it. At present it looks for an install of Rock Box on the device, which in this scenario wouldn't be there. Banshee would also need to download the latest installer, which shouldn't be too bad as its very lightweight. It may be better to have it as a separate extension or part of the parent DAP extension. I am not sure how we would make sure we only offer the install button for supported devices, since there are many devices it can't be installed on and many it can be. I guess we would end up with a list of valid vendor IDs or may be we can just let the installer take care of that scenario. It might be something worth asking on the RockBox mailing list. They were quite helpful with regard to my questions about writing the Tag Cache DB.
Charlie, now that 1.5.0 is about ready to go out the door maybe it is time to propose this once more for review. It is a killer feature and I hope you are still working on it.
Please attach the patch as a diff. If you update it against git master (we've moved from svn to git) you can easily make patches that include new files etc.
To be honest, I havn't done much with it recently. If I get time I will look at it at the weekend. I need to try adding it to the latest version. The basic Rockbox parts work fine. Its the integration with the rest of Banshee thats the biggest weakness of the code at the moment. I am not sure how much the DAP stuff has changed recently. It was undergoing heavy change when I started work on it. The biggest issue is still how to stop the rest of banshee from trying to use the device. I spent quite a while trying to track down how the other plugins always get first refusal on the device. As it currently needs every other compatible DAP plugin disabled first. I never got to the bottom of that. Assuming I can get it working with the latest code base. I could really do with a bit of assistance from someone who knows the Bnashee code base a bit better. I will report back if I make any progress.
For the time being - I have found that putting the following .is_audio_player file on the device makes it work great with rockbox (music, podcasts, playlists, coverart all sync flawlessly). It would be awesome if there were integration with the DB, but since rockbox is capable of building it's on DB, this is not too important to me. audio_folders=Music/,Videos/ video_folders=Videos/ folder_depth=2 output_formats=application/ogg,audio/x-ms-wma,audio/mpeg,audio/mp4,audio/x-wav playlist_format=audio/x-mpegurl playlist_path=Playlists/ cover_art_file_name=cover.jpg cover_art_file_type=jpeg cover_art_size=320 I am going to try to create a rockbox plugin based on the Android one that I am now pretty familiar with. The key I think is to give iPod users with a .rockbox directory on their device a choice of whether they want to sync to the iPod DB - or to treat it as a rockbox device with the following settings. Having Banshee do something different if it finds a .rockbox directory should be easy since the code already does something different if it finds the .is_audio_player file. The hard part I think is writing in the option.
Created attachment 139431 [details] [review] New Patch if .rockbox/config.cfg is found - treat the device as mass storage with rockbox settings. Here is a patch that causes and devices with a .rockbox/config.cfg (all rockbox systems) to be treated as a mass storage device with the following settings: audio_folders=Music/,Videos/ video_folders=Videos/ folder_depth=2 output_formats=application/ogg,audio/x-ms-wma,audio/mpeg,audio/mp4,audio/x-wav playlist_format=audio/x-mpegurl playlist_path=Playlists/ cover_art_file_name=cover.jpg cover_art_file_type=jpeg cover_art_size=320 I tested with and without an .is_audio_player file and it works great - music, podcasts, playlists, videos and coverart are all synced. The DB is not written to however. Perhaps Charlie can add that. But, I don't think it is too important because RockBox can create its own DB.
Created attachment 139433 [details] [review] Patch to treat a device as a Mass Storage with rockbox settings if a .rockbox/config.cfg file is found. Ooops, last patch was for a different bug. Here is the correct one.
Created attachment 139436 [details] [review] Patch to treat a device as a Mass Storage with rockbox settings if a .rockbox/config.cfg file is found. Slightly updated patch so device correctly identifies as a "RockBox Device"
Also, I should mention that the patch here depends on the patch from http://bugzilla.gnome.org/show_bug.cgi?id=589829 because I use the video_folders variable.
How do you plan to address Rockbox devices with different capability lists, hand editing .is_audio_player files makes grandma cry, isn't there a way we can poll that information from Rockbox? Additionally I don't think it's wise to dismiss database creation on the computer, my Netbook certainly can do that faster and it won't drain my devices available power. For a first generation support patch sure but eventually there would be benefits to be had from this.
There is no need for .is_audio_player anymore. The settings above are hardcoded into the source included in the patch. I believe they should be appropriate for all rockbox devices. For example there is nothing special about the cover art size I chose. It is just large enough for the biggest device. Rockbox displays a resized image to fit a particular theme, and different themes can have different sizes so syncing a large size is best. A few devices need different video sizes/formats, but this feature is missing across Banshee in general. When Banshee starts transcoding videos, we can worry about detecting these settings. For now, it is up to the user. I agree that adding functionality to sync the DB would be awesome and perhaps Charlie can add it. It would be easy to add another variable (like has_rockbox) so that the actual syncing routine can do something different. I think leaving this feature out is a reasonable first step in Rock Box integration, however. And is a lot better than the current situation.
Thanks Jack, committed (slightly modified)