Rock Box and iPod DAP extensions

[Charlie.M]

Hi All,

I was wondering what everyone's thoughts on how best to handle the
choosing of which extension to use when syncing a Rock Box player. My
extension is designed to work directly with Rock Box's DB, however
since a large number of the Rock Box users are iPod users this leaves
quite a complex number of use cases.

Some users may want to use both the original firmware and the Rock Box
one (its perfectly capable of dual booting the player). In which case
they will probably want to use the standard iPod syncing and let the
device update its own Rock Box DB to match. If they aren't going to
use the original firmware then they will probably want to use my
extension since it will access the Rock Box DB directly and provide a
much better syncing experience.

With all the default extensions enabled, when I insert my iPod (which
I am using with Rock Box) the iPod extension loads it as a
conventional iPod, my extension doesn't load. I have to disable the
iPod extension to give the Rock Box extension a chance to load.

There's a simple way to check if Rock Box is installed, it stores all
the Rock Box software in a folder called .rockbox in the root of the
devices file system, therefore if its not present Rock Box can't be
installed.

I could patch the iPod extension not to load any iPod with Rock Box
installed but what about the users that want to use both firmwares and
stick with the conventional iPod syncing. It seems to me we really
need to ask iPod users on a per device basis, if they have Rock Box
installed. Perhaps we could store a hidden file on the player
containing the user choice, so every time banshee detects it, it uses
the correct syncing extension.

What does everyone think?

Charlie M
_______________________________________________
Banshee-list mailing list
Banshee-list@...
http://mail.gnome.org/mailman/listinfo/banshee-list

[David Nielsen-2]

2008/10/17 Charles Mason <charlie.mas@...>

Hi All,

I was wondering what everyone's thoughts on how best to handle the
choosing of which extension to use when syncing a Rock Box player. My
extension is designed to work directly with Rock Box's DB, however
since a large number of the Rock Box users are iPod users this leaves
quite a complex number of use cases.

Some users may want to use both the original firmware and the Rock Box
one (its perfectly capable of dual booting the player). In which case
they will probably want to use the standard iPod syncing and let the
device update its own Rock Box DB to match. If they aren't going to
use the original firmware then they will probably want to use my
extension since it will access the Rock Box DB directly and provide a
much better syncing experience.

With all the default extensions enabled, when I insert my iPod (which
I am using with Rock Box) the iPod extension loads it as a
conventional iPod, my extension doesn't load. I have to disable the
iPod extension to give the Rock Box extension a chance to load.

There's a simple way to check if Rock Box is installed, it stores all
the Rock Box software in a folder called .rockbox in the root of the
devices file system, therefore if its not present Rock Box can't be
installed.

I could patch the iPod extension not to load any iPod with Rock Box
installed but what about the users that want to use both firmwares and
stick with the conventional iPod syncing. It seems to me we really
need to ask iPod users on a per device basis, if they have Rock Box
installed. Perhaps we could store a hidden file on the player
containing the user choice, so every time banshee detects it, it uses
the correct syncing extension.

What does everyone think?

All Rockbox modified iPod should contain a .is_audio_player file in the root dir. This is needed to tell us things like where to place files, what formats are supported etc. When that file is present Banshee will not open it as an iPod but rather as a USB mass storage device. Does that solve your dilemma?

This would also mean that you would have to lobby upstream to amend their installation guides to include such a file, or you could install it yourself if the conditions are present (ipod plugged in, .rockbox found, model known and has matching .is_audio_player file to reflect capabilities).

Another question might be what we can do to unify the two interfaces in the future. Stock iPod firmware has a much easier layout, relies directly on the db and hides all the debugging entries in the interface. You also have seperate control for podcasts, video and music based on their differing needs. This could definitely be made nicer especially since we already have a lot of information from Banshee that could be carried over. Working with upstream here maybe on a special spin of Rockbox would probably be the way forward.

_______________________________________________
Banshee-list mailing list
Banshee-list@...
http://mail.gnome.org/mailman/listinfo/banshee-list

[Charlie.M]

2008/10/17 David Nielsen <gnomeuser@...>:

>
>
> 2008/10/17 Charles Mason <charlie.mas@...>
>>
>> Hi All,
>>
>> I was wondering what everyone's thoughts on how best to handle the
>> choosing of which extension to use when syncing a Rock Box player. My
>> extension is designed to work directly with Rock Box's DB, however
>> since a large number of the Rock Box users are iPod users this leaves
>> quite a complex number of use cases.
>>
>> Some users may want to use both the original firmware and the Rock Box
>> one (its perfectly capable of dual booting the player). In which case
>> they will probably want to use the standard iPod syncing and let the
>> device update its own Rock Box DB to match. If they aren't going to
>> use the original firmware then they will probably want to use my
>> extension since it will access the Rock Box DB directly and provide a
>> much better syncing experience.
>>
>> With all the default extensions enabled, when I insert my iPod (which
>> I am using with Rock Box) the iPod extension loads it as a
>> conventional iPod, my extension doesn't load. I have to disable the
>> iPod extension to give the Rock Box extension a chance to load.
>>
>> There's a simple way to check if Rock Box is installed, it stores all
>> the Rock Box software in a folder called .rockbox in the root of the
>> devices file system, therefore if its not present Rock Box can't be
>> installed.
>>
>> I could patch the iPod extension not to load any iPod with Rock Box
>> installed but what about the users that want to use both firmwares and
>> stick with the conventional iPod syncing. It seems to me we really
>> need to ask iPod users on a per device basis, if they have Rock Box
>> installed. Perhaps we could store a hidden file on the player
>> containing the user choice, so every time banshee detects it, it uses
>> the correct syncing extension.
>>
>> What does everyone think?
>
> All Rockbox modified iPod should contain a .is_audio_player file in the root
> dir. This is needed to tell us things like where to place files, what
> formats are supported etc. When that file is present Banshee will not open
> it as an iPod but rather as a USB mass storage device. Does that solve your
> dilemma?
>
> This would also mean that you would have to lobby upstream to amend their
> installation guides to include such a file, or you could install it yourself
> if the conditions are present (ipod plugged in, .rockbox found, model known
> and has matching .is_audio_player file to reflect capabilities).
>
> Another question might be what we can do to unify the two interfaces in the
> future. Stock iPod firmware has a much easier layout, relies directly on the
> db and hides all the debugging entries in the interface. You also have
> seperate control for podcasts, video and music based on their differing
> needs. This could definitely be made nicer especially since we already have
> a lot of information from Banshee that could be carried over. Working with
> upstream here maybe on a special spin of Rockbox would probably be the way
> forward.

I am working on a new Banshee extension for Rock Box Syncing.
Basically it reads and writes the hidden Rock Box DB file format in a
similar to the way the iPod extension works. So when the device is
inserted its track listings load in a few seconds rather than the
several minutes it takes using the generic Mass Storage extension.
This also means the rock box software doesn't have to scan the device
for changes to update its DB which literally saves several minutes per
sync on an iPod sized player.

I have been working with the upstream Rock Box project to iron out a
few missing details form the Rock Box DB specification documentation.
I now have my new extension reading and writing the Rock Box DB
properly. It even dirties the DB once changes are made, so if the user
doesn't eject it properly Rock Box will automatically rebuild the DB
itself. Some of the Rock Box developers seem quite keen to get better
integration between music players and Rock Box.

My problem is the iPod extension effectively grabs the device before
the new Rock Box one so it can't load the device. I was thinking of
modifying the iPod extension to ask the user if they have Rock Box
installed how they want to sync it. If they indicate they don't want
to sync the iPod DB it simply rejects the device as if it had the Mass
Storage .is_audio_player file. Then the Rock Box extension could pick
it up. I was thinking of storing this response on the player so the
user isn't asked every time.

Charlie M
_______________________________________________
Banshee-list mailing list
Banshee-list@...
http://mail.gnome.org/mailman/listinfo/banshee-list

[David Spreen]

"Charles Mason" <charlie.mas@...> writes:

> 2008/10/17 David Nielsen <gnomeuser@...>:
> My problem is the iPod extension effectively grabs the device before
> the new Rock Box one so it can't load the device. I was thinking of
> modifying the iPod extension to ask the user if they have Rock Box
> installed how they want to sync it. If they indicate they don't want
> to sync the iPod DB it simply rejects the device as if it had the Mass
> Storage .is_audio_player file. Then the Rock Box extension could pick
> it up. I was thinking of storing this response on the player so the
> user isn't asked every time.

The iPod extension doesn't touch the device if a .is_audio_player file
is present in the root directory. You need this becuase it helps people
configure album_art size (look at how the dap plugin does this, this was
explicitely designed for rockbox).

Please, rather add a field to the is_audio_player that has something
like is_rockbox or better even rockbox_version (in case we need to deal
with compatibility issues in the future). If that field is present, use
rockbox extension.

Is your code public somewhere so people can have a look? In any case,
thanks for your work.

Best Wishes,

David
_______________________________________________
Banshee-list mailing list
Banshee-list@...
http://mail.gnome.org/mailman/listinfo/banshee-list

[Charlie.M]

On Tue, Oct 21, 2008 at 5:54 PM, David Spreen <netzwurm@...> wrote:

> "Charles Mason" <charlie.mas@...> writes:
>
>> 2008/10/17 David Nielsen <gnomeuser@...>:
>> My problem is the iPod extension effectively grabs the device before
>> the new Rock Box one so it can't load the device. I was thinking of
>> modifying the iPod extension to ask the user if they have Rock Box
>> installed how they want to sync it. If they indicate they don't want
>> to sync the iPod DB it simply rejects the device as if it had the Mass
>> Storage .is_audio_player file. Then the Rock Box extension could pick
>> it up. I was thinking of storing this response on the player so the
>> user isn't asked every time.
>
> The iPod extension doesn't touch the device if a .is_audio_player file
> is present in the root directory. You need this becuase it helps people
> configure album_art size (look at how the dap plugin does this, this was
> explicitely designed for rockbox).

I can the problem is rockbox doesn't install a .is_audio_player file
it has to be created manually. I was hopping to let it detect a clean
install of Rock Box. Since if we know its Rock Box much of the need
the files fields goes away or at the least it can provide sensible
defaults.

The extension currently just uses 100x100 sized artwork however Rock
Box now supports multiple sizes so the Rock Box theme can select the
most appropriate artwork since RockBox can't resize it on the fly.

Can't we get the DAP extension to detect if Rock Box is installed via
the .rockbox folder. Then if it is give the user the option via a
dialogue box and store the result in a field in a new .is_audio_player
or something similar.

> Please, rather add a field to the is_audio_player that has something
> like is_rockbox or better even rockbox_version (in case we need to deal
> with compatibility issues in the future). If that field is present, use
> rockbox extension.

Well the Rock Box DB file has its own version header, so it already
reads that to check its compatibility. RockBox also has a file which
contains the RockBox version and lots of info about the device,
although it currently doesn't parse that.

> Is your code public somewhere so people can have a look? In any case,
> thanks for your work.

Its not yet although after a bit of a clean up I shall post a patch
for it. I am a little unsure of the correct procedure for integrating
it in to the banshee build system. I have hacked the make system to
build it like it does the other DAP extensions but I am unsure of how
to make it optional during configure like the others DAP extensions.
To be honest Make and Automake are a bit of a mystery to me I am more
used to nant and msbuild. It would be helpful if someone how does
understand them can point me in the right direction.

The other problem I am currently having is syncing playlists. I can
drag and drop them or get it to sync their tracks, but I would like to
actually get the playlists themselves syncing as .m3u files to the
device. I have tried to follow the iPod extension, but when it comes
to sync it finds two playlist sources both null. I will have to
investigate that further.

I also need to clean it up a bit to meet the Banshee code style guide
lines. As at the early stages it was more of a proof of concept.

Thanks for the info.

Charlie M
_______________________________________________
Banshee-list mailing list
Banshee-list@...
http://mail.gnome.org/mailman/listinfo/banshee-list

[David Spreen]

Hey Charles,

Are you still on this? would you mind opening a bug and attaching your
patch so that other folks can have a look? I am very interested in
helping out. If you don't want to make the patch public yet, could you
send it to me?

Best Wishes,

David
_______________________________________________
banshee-list mailing list
banshee-list@...
http://mail.gnome.org/mailman/listinfo/banshee-list

[David Spreen-3]

Hi again,

if you could just provide me with the code you wrote to create the
tagcache for rockbox, I would like to write a simple plugin that just
updates the tagcache. Apart from that rockbox already works fine with
the mass-storage plugin (which already includes configurable support for
rockbox cover art etc., so if we could just write a plugin that updates
the tagcache after every sync (from what's on the player, that way we
don't have to worry about recopying files), things would be a lot
better.

Best,

David

David Spreen <netzwurm@...> writes:

> Hey Charles,
>
> Are you still on this? would you mind opening a bug and attaching your
> patch so that other folks can have a look? I am very interested in
> helping out. If you don't want to make the patch public yet, could you
> send it to me?
>
> Best Wishes,
>
> David

_______________________________________________
banshee-list mailing list
banshee-list@...
http://mail.gnome.org/mailman/listinfo/banshee-list

[Charlie.M]

On Thu, Nov 20, 2008 at 5:32 PM, David Spreen
<david.spreen@...> wrote:

> Hi again,
>
> if you could just provide me with the code you wrote to create the
> tagcache for rockbox, I would like to write a simple plugin that just
> updates the tagcache. Apart from that rockbox already works fine with
> the mass-storage plugin (which already includes configurable support for
> rockbox cover art etc., so if we could just write a plugin that updates
> the tagcache after every sync (from what's on the player, that way we
> don't have to worry about recopying files), things would be a lot
> better.

Sorry I havn't got back to you sooner, been distracted by work and
another project.

I have just uploaded it to the projects Bugzilla.
http://bugzilla.gnome.org/show_bug.cgi?id=561712

The version of Bugzilla has been tested with the current SVN and
appears to work fine.

The Tag Cache reading and writing is contained in two classes (with
TagCache in their names) so it should be quite straight forward to add
to whatever you like.

Let me know if you have any problems or have any thoughts.


Charlie M
_______________________________________________
banshee-list mailing list
banshee-list@...
http://mail.gnome.org/mailman/listinfo/banshee-list

[Charlie.M]

On Thu, Nov 20, 2008 at 5:32 PM, David Spreen
<david.spreen@...> wrote:

> Hi again,
>
> if you could just provide me with the code you wrote to create the
> tagcache for rockbox, I would like to write a simple plugin that just
> updates the tagcache. Apart from that rockbox already works fine with
> the mass-storage plugin (which already includes configurable support for
> rockbox cover art etc., so if we could just write a plugin that updates
> the tagcache after every sync (from what's on the player, that way we
> don't have to worry about recopying files), things would be a lot
> better.

The problem with just writing the DB and not reading it would be how
does Banshee know what's already on the device? The only way it can is
by scanning the music folders which takes a very long time. In my own
test on reasonably full 30gig iPod that took several minutes, where as
getting the data from the tag cache takes only a couple seconds
exactly like using Apple's iPod DB.

The current problem I am having with syncing is that the DAP
extension's sync system for whatever reason doesn't think the files in
the Library are the same as those on the device. So it requests all
existing files be removed and copies back all the new ones. They show
up correctly in Bashee's track list and can be played directly off the
device. It all works fine just that it takes ages to sync because of
all the unnecessary file IO. I am sure its something fairly simple to
fix. Its just a matter of following through exactly what meta data
Banshee bases its syncing decision on and working out what's confusing
it. All the key Meta data is present in the devices tracks listing
(such as Artists, Album Artist, Track Name, .....).

The problem with the tag cache DB format is that its hard to append
new entries directly on the disk. From reading the RockBox source and
as the name suggests its used directly by the RockBox menu system.
Because of this most of the tag files need to maintain a correct
sorted order so you can't simply append new entries to them. I think
that's one reason why in RockBox it takes so long to update.

In my plugin it loads all the DBs data in to memory then adds /
removes new entries and rewrites the whole DB structure back out. On
the PC side we have many resources so its not really a major problem
compared to the Rock Box Player. On my 4 year old PC it only takes a
second or two every time its ejected for a reasonably sized DB.

It does mean the device needs to be properly ejected so the new DB can
be written when the device is manually managed. When its synced it
simply writes the new DB after the sync cycle completes. When the
first change is made to the player (adding or removing tacks) it sets
the Tag Cache DB's dirty flag. This means if the DB isn't properly
written the device will regenerate it when the user next accesses the
DB. The last stage of writing the DB is setting this flag back to
clean. My plugin has a dialogue which informs the user of this if its
not properly ejected. Worst case scenario is the DB needs to be
rebuilt by the device which is the best case scenario if the user were
to just use the existing mass storage extension.

Incidentally the version on bugzilla works correctly with play lists
now. So if you sync, all the play lists get copied over and work fine
in Rock Box. I would really like to be able to manually sync playlists
as well, although I think that requires work in the DAP extension to
support it.

I am quite keen to have a Rock Box extension with the same
functionality and out of the box simplicity as the iPod extension. I
think I am very close to that with the current version of the Rock Box
extension. If you want to integrate the tag cache support in to the
highly configurable Mass Storage extension for users who want complete
control over their device then by all means.

The other option is that configurableity could be added to the new
Rock Box extension and just let it assume sensible defaults so it
works out of the box. Since it knows its a Rock Box player it can
assume a lot more and perhaps provide Rock Box Specific functionality
which would be hard to generalise to all Mass Storage players.


Charlie M
_______________________________________________
banshee-list mailing list
banshee-list@...
http://mail.gnome.org/mailman/listinfo/banshee-list

[David Spreen]

"Charles Mason" <charlie.mas@...> writes:

> On Thu, Nov 20, 2008 at 5:32 PM, David Spreen
> <david.spreen@...> wrote:
>
> The problem with just writing the DB and not reading it would be how
> does Banshee know what's already on the device? The only way it can is
> by scanning the music folders which takes a very long time.

This could be integrated in the mass-storage plug-in. If there is a
rockbox db, read it, otherwise don't.

> I am quite keen to have a Rock Box extension with the same
> functionality and out of the box simplicity as the iPod extension. I
> think I am very close to that with the current version of the Rock Box
> extension. If you want to integrate the tag cache support in to the
> highly configurable Mass Storage extension for users who want complete
> control over their device then by all means.

This makes little sense to me. The whole point of Rockbox is that it is
extremely configurable and adaptable to many different use-cases. There
is no standard size for cover art, for example and there are different
themes that require different images.

I have nothing against setting reasonable defaults but generally you
can't assume these settings as they differ from device to device and
from configuration to configuration.

> The other option is that configurability could be added to the new
> Rock Box extension and just let it assume sensible defaults so it
> works out of the box. Since it knows its a Rock Box player it can
> assume a lot more and perhaps provide Rock Box Specific functionality
> which would be hard to generalize to all Mass Storage players.

I just don't know why there needs to be a separate rock box extension
since the mass-storage extension supports everything except the database
handling. If we could extend mass-storage with your tag-cache code so it
doesn't get in the way of non-rockbox players we could save a lot of
work when implementing new features that affect both, ordinary
mass-storage and rockbox players.

In any case, great job writing that code. What do other people think?
Could we get some input from the maintainers? How would you like to
integrate this into banshee?

Best,

David
_______________________________________________
banshee-list mailing list
banshee-list@...
http://mail.gnome.org/mailman/listinfo/banshee-list

[gabaug]

On Fri, Nov 21, 2008 at 6:07 PM, David Spreen <netzwurm@...> wrote:
> In any case, great job writing that code. What do other people think?
> Could we get some input from the maintainers? How would you like to
> integrate this into banshee?

Yeah, great job Charlie, it sounds like you've done a lot of good work.

David, I agree that if possible we should make this a
CustomMassStorageDevice subclass.

Gabriel
_______________________________________________
banshee-list mailing list
banshee-list@...
http://mail.gnome.org/mailman/listinfo/banshee-list

[Charlie.M]

On Sat, Nov 22, 2008 at 12:14 AM, Gabriel Burt <gabriel.burt@...> wrote:
> On Fri, Nov 21, 2008 at 6:07 PM, David Spreen <netzwurm@...> wrote:
>> In any case, great job writing that code. What do other people think?
>> Could we get some input from the maintainers? How would you like to
>> integrate this into banshee?
>
> Yeah, great job Charlie, it sounds like you've done a lot of good work.
>
> David, I agree that if possible we should make this a
> CustomMassStorageDevice subclass.

What I was really trying to get away from was the need for the user to
edit any hidden files before they can sync their device. If they
decide they want to tweak some default setting then fair enough but it
shouldn't be a requirement. Rock Box now has a very slick installer so
it would be nice to provide a similar seemless syncing experience
comparable with the iPod one. It doesn't necessarily need to be a
separate extension just one that has some specific knowledge of
RockBox rather than just being able to read and write the tag cache
DB. I admit there is a lot of overlap with the Mass Storage extension.

I suppose knowing its a Rock Box player banshee could just generate a
default config file with workable defaults. There will need to be some
consideration made for iPods which of course could be synced in the
tradtional way or via Rock Box. Some users may have experimented with
Rockbox so have a .rockbox folder but still want to sync with the
iTunes DB, so I think banshee would have to ask the user if it detects
multiple options.

To be honest I imagine there quite a few occasions where banshee has
multiple syncing solutions available. It would be nice to have a
general way of letting them choose the one they want to use. That way
any future DAP extensions could by more easily integrated without
having to worry about the interests and capabilities of the existing
extensions.

Could we modify the DAP extension to let each enabled DAP extension
decide if it is interested in the device, rather than doing it on a
first come first served basis as it is at the moment. If there are
more than one then display a dialogue asking the user along with a
sentence about the merits of each of the interested DAP extensions.
There could also be a check box to let the user save their choice.

Perhaps there could be a confidence rating from each DAP extension as
well. If you have a normal iPod you could use the Mass Storage but
chances are you want the iPod extension but if you have Rock Box
installed you probably want to use that extension rather than the
other two options. The GUI could display the DAP extension choice in
descending order so the most likely option is at the top.

What does everyone think?


Charlie M
_______________________________________________
banshee-list mailing list
banshee-list@...
http://mail.gnome.org/mailman/listinfo/banshee-list

[Bertrand Lorentz]

On Tue, 2008-11-25 at 15:48 +0000, Charles Mason wrote:

> On Sat, Nov 22, 2008 at 12:14 AM, Gabriel Burt <gabriel.burt@...> wrote:
> > On Fri, Nov 21, 2008 at 6:07 PM, David Spreen <netzwurm@...> wrote:
> >> In any case, great job writing that code. What do other people think?
> >> Could we get some input from the maintainers? How would you like to
> >> integrate this into banshee?
> >
> > Yeah, great job Charlie, it sounds like you've done a lot of good work.
> >
> > David, I agree that if possible we should make this a
> > CustomMassStorageDevice subclass.
>
> What I was really trying to get away from was the need for the user to
> edit any hidden files before they can sync their device. If they
> decide they want to tweak some default setting then fair enough but it
> shouldn't be a requirement. Rock Box now has a very slick installer so
> it would be nice to provide a similar seemless syncing experience
> comparable with the iPod one.

Being a Rockbox user (on my Sansa e280), I'm all for seamless experience
with it.
For instance, I was able to get proper cover art transfered to my DAP by
editing the .is_audio_player file, but that could easily be handled by
having a CustomMassStorageDevice subclass. Like the AndroidDevice class.

The only problem I see now is that the choice of the
CustomMassStorageDevice subclass is based on the HAL vendor id and
product id. Obviously, for Rockbox that's useless. We'd need to check if
there's a .rockbox directory at the root of the device.

Any ideas about the best way to handle this ?

--
Bertrand Lorentz <bertrand.lorentz@...>
> http://flickr.com/photos/bl8/ <


_______________________________________________
banshee-list mailing list
banshee-list@...
http://mail.gnome.org/mailman/listinfo/banshee-list

[Charlie.M]

2008/11/25 Bertrand Lorentz <bertrand.lorentz@...>:

> On Tue, 2008-11-25 at 15:48 +0000, Charles Mason wrote:
>> On Sat, Nov 22, 2008 at 12:14 AM, Gabriel Burt <gabriel.burt@...> wrote:
>> > On Fri, Nov 21, 2008 at 6:07 PM, David Spreen <netzwurm@...> wrote:
>> >> In any case, great job writing that code. What do other people think?
>> >> Could we get some input from the maintainers? How would you like to
>> >> integrate this into banshee?
>> >
>> > Yeah, great job Charlie, it sounds like you've done a lot of good work.
>> >
>> > David, I agree that if possible we should make this a
>> > CustomMassStorageDevice subclass.
>>
>> What I was really trying to get away from was the need for the user to
>> edit any hidden files before they can sync their device. If they
>> decide they want to tweak some default setting then fair enough but it
>> shouldn't be a requirement. Rock Box now has a very slick installer so
>> it would be nice to provide a similar seemless syncing experience
>> comparable with the iPod one.
>
> Being a Rockbox user (on my Sansa e280), I'm all for seamless experience
> with it.
> For instance, I was able to get proper cover art transfered to my DAP by
> editing the .is_audio_player file, but that could easily be handled by
> having a CustomMassStorageDevice subclass. Like the AndroidDevice class.
>
> The only problem I see now is that the choice of the
> CustomMassStorageDevice subclass is based on the HAL vendor id and
> product id. Obviously, for Rockbox that's useless. We'd need to check if
> there's a .rockbox directory at the root of the device.
>
> Any ideas about the best way to handle this ?

Well checking for the .rockbox directory is a start but you still have
to think about iPods and other devices which can be used via
completely separate DAP extensions. I have developed a Rockbox
extension (the source is on the project Bugzilla) but if you use an
iPod currently the iPod extension needs to be disabled and you have no
.is_audio_player file only then does my extension get the opportunity
to check for the .rockbox directory and attempt to read the Tag Cache
DB.

I think in the long run Banshee is going to have to byte the bullet
and actually ask the user. We can build a massive DB of vendor IDs and
the logic to choose the best option for the user but its never going
to be perfect. I think long term the solution I outlined earlier in
this thread is the way to go.


Charlie
_______________________________________________
banshee-list mailing list
banshee-list@...
http://mail.gnome.org/mailman/listinfo/banshee-list

[mirth18]

I know this thread is almost a year old, but did this RockBox extension every come to fruition?  I am very interested in syncing playcounts and such stats from my Sansa e200 running RockBox with Banshee.

Has anyone had any luck with doing this sort of thing?

Nick

Charlie.M wrote:

On Tue, Oct 21, 2008 at 5:54 PM, David Spreen <[e-mail]> wrote:
> "Charles Mason" <[e-mail]> writes:
>
>> 2008/10/17 David Nielsen <[e-mail]>:
>> My problem is the iPod extension effectively grabs the device before
>> the new Rock Box one so it can't load the device. I was thinking of
>> modifying the iPod extension to ask the user if they have Rock Box
>> installed how they want to sync it. If they indicate they don't want
>> to sync the iPod DB it simply rejects the device as if it had the Mass
>> Storage .is_audio_player file. Then the Rock Box extension could pick
>> it up. I was thinking of storing this response on the player so the
>> user isn't asked every time.
>
> The iPod extension doesn't touch the device if a .is_audio_player file
> is present in the root directory. You need this becuase it helps people
> configure album_art size (look at how the dap plugin does this, this was
> explicitely designed for rockbox).

I can the problem is rockbox doesn't install a .is_audio_player file
it has to be created manually. I was hopping to let it detect a clean
install of Rock Box. Since if we know its Rock Box much of the need
the files fields goes away or at the least it can provide sensible
defaults.

The extension currently just uses 100x100 sized artwork however Rock
Box now supports multiple sizes so the Rock Box theme can select the
most appropriate artwork since RockBox can't resize it on the fly.

Can't we get the DAP extension to detect if Rock Box is installed via
the .rockbox folder. Then if it is give the user the option via a
dialogue box and store the result in a field in a new .is_audio_player
or something similar.

> Please, rather add a field to the is_audio_player that has something
> like is_rockbox or better even rockbox_version (in case we need to deal
> with compatibility issues in the future). If that field is present, use
> rockbox extension.

Well the Rock Box DB file has its own version header, so it already
reads that to check its compatibility. RockBox also has a file which
contains the RockBox version and lots of info about the device,
although it currently doesn't parse that.

> Is your code public somewhere so people can have a look? In any case,
> thanks for your work.

Its not yet although after a bit of a clean up I shall post a patch
for it. I am a little unsure of the correct procedure for integrating
it in to the banshee build system. I have hacked the make system to
build it like it does the other DAP extensions but I am unsure of how
to make it optional during configure like the others DAP extensions.
To be honest Make and Automake are a bit of a mystery to me I am more
used to nant and msbuild. It would be helpful if someone how does
understand them can point me in the right direction.

The other problem I am currently having is syncing playlists. I can
drag and drop them or get it to sync their tracks, but I would like to
actually get the playlists themselves syncing as .m3u files to the
device. I have tried to follow the iPod extension, but when it comes
to sync it finds two playlist sources both null. I will have to
investigate that further.

I also need to clean it up a bit to meet the Banshee code style guide
lines. As at the early stages it was more of a proof of concept.

Thanks for the info.

Charlie M
_______________________________________________
Banshee-list mailing list
[e-mail]
http://mail.gnome.org/mailman/listinfo/banshee-list

[kingsinger]

I'm in the same boat. I've got a sansa e250 with an 8gb micro sdhc card running Rockbox 3.4.

I'd love to be able to sync some smart playlists between the computer and the player, but reciprocal database sync is necessary to make that happen.

If this plug-in was working, it sounds like just the ticket.

Personally, I don't care if I have to edit .is audio player file on my player or some of the other fine points discussed further up this thread. Now that RB supports usb connection natively, I don't have much reason to use the stock Sansa firmware. I bought the player to use RB from the start.

Will the plug-in allow you to sync a subset of a large library to a player (say a particular playlist) and then sync the databases accordingly, like ipod/itunes?

If it syncs the play counts, etc. I'm willing to futz with some stuff, as long as I don't have to get into really techie stuff around compiling source code and stuff.

KS