Rejection of "ignore the" patch (split from the Evil_G unsupported build thread)

[Llorean]

Yes, I pointed that it's part of several standards at the beginning of the explanation. The problem is, people seem to think that the software they choose to use is the only software that exists/matters. They also don't think spreading the use of a good standard is a good idea.

I think I'm going to state that from here on out, the argument for "Ignore The" that goes "It's easier / more convenient for my personal method of using it" is restricted. We get the point, we know you LIKE it better, but the idea has been rejected. Arguing for it accomplishes nothing, and since these forums are for discussing the state of official Rockbox, unless you have a new argument for it that you think will change the situation, you don't need to repeat what you've said in favour of it yet again.

[soap]

I just want to clarify that I am not against using a pluggin as a solution to doing the tagging.  I was simply trying to dispel what I saw as an argument against a PC side application based upon faulty assumptions.

[lalittle]

No - you merely retag files while they reside on your DAP.  You keep stressing this point, but it is an invalid one.

My point is not invalid -- there is simply a lack of clear communication on this point.  Editing these tags outside of Rockbox requires a program that can see and edit these tags, and it requires a script made specifically to do this.  This doesn't inherently exist with many of the mainstream audio management programs -- i.e. you can't necessarily do this in many of the most widely used applications used for this.  It would most likely require that a new, separate program be downloaded and installed, and a custom script run on the library.  After this, since the files had changed, it could likely require the audio management library to be manually "updated" in order to show the correct information for these files.

There is no need for this process to interfere with your music management program of choice.

Again, the mere fact that you'd likely need another, third party program is already a factor, not to mention the fact that re-writing the tags in different applications carries the "potential" (however unlikely) of extra problems.  These issues are completely eliminated if the actual unit is used to complete this task.  Also, given that at this time, for most users, Rockbox would be the only item that actually made use of these tags (iTunes, JR Media Center and other apps don't use them for their "ignore articles" sorting) it makes sense to put this functionality into Rockbox, allowing users to obtain article free sorting without the need of anything other than the Rockboxed unit itself.  This seems like a terrific feature that a lot of people who use iTunes or other mainstream apps would take advantage of.

As opposed to Rockbox users needing to have prior knowledge of the plugin?

The idea is that it would eventually be incorporated into the official build, which Llorean already indicated could be the case when he said "And a plugin like that could surely get accepted into SVN, meaning you wouldn't have to have the hassle of using an unsupported build and depending on someone else for your updates or maintaining the patch."  Once this was the case, it would appear in the menu, which would make it visible to anyone without requiring prior knowledge of it's existence.

Not to split hairs, but it will be a pluggin, not a menu item.

I don't understand -- all sorts of plugins have "menu items."  Take the iPod "Scroll Wheel Acceleration" for example.  This adds adjustments for this feature to the menus.

Failure to read the manual affects people's knowledge and understanding of the "Random Folder Advance" pluggin.  How would this one be different?

I don't follow you here.  My point was simply that with the myriad of features contained in Rockbox, having a menu item would alert people to the presence of this feature.  I support the idea of reading the manual, but I also know that this can be a daunting task for a complex item like this, so I also support the idea of making features more "visible," and therefor more "accessible" to the general user base.  This is simply the idea of making things more "user friendly."

Straw man - a broken tagger is a broken tagger.  A pluggin would be modifying your tags in the exact same fashion as a PC side app.

My point was that the original files that reside on the PC would be untouched.  Only the files on the Rockbox would be effected if the Rockbox itself took care of this duty.

Larry

[Llorean]

Scroll wheel acceleration is not a plugin.  Plugins are anything you seen in "browse plugins" or any viewers. Basically, files with the extension .rock. They do NOT show up in the main menus, with one exception (the credits plugin).

You seem to have confused it with the term "patch".

A PC-side program could very easily be run on the files on the DAP.

And I don't believe Rockbox should ever be forced to restrict or limit itself for fear of offending other programs that don't adhere to standards. "Fear of incompatibility" is silly, if that incompatibility is with a program that doesn't support a standard it claims to. If we add support for a standardized format, and another program can't deal with it that's supposed to also support that format, bug reports should be directed to them, rather than requests to us to remove (or in this case not add) or hack around that broken support.

[lalittle]

I think I'm going to state that from here on out, the argument for "Ignore The" that goes "It's easier / more convenient for my personal method of using it" is restricted. We get the point, we know you LIKE it better, but the idea has been rejected. Arguing for it accomplishes nothing, and since these forums are for discussing the state of official Rockbox, unless you have a new argument for it that you think will change the situation, you don't need to repeat what you've said in favour of it yet again.

Wait -- did you think I was still arguing for the straight-out "ignore" approach?  If so, I've been very unclear.  What I've been trying to support in these recent posts is the idea originally suggested by safetydan above, where he suggested using the advanced tags for the "core" of the sorting function, but using a plugin to create these tags on the Rockbox itself.  This is what I said earlier "gets my vote," and what I've been attempting to support with these recent posts.

Thanks,

Larry

[lalittle]

Scroll wheel acceleration is not a plugin.  Plugins are anything you seen in "browse plugins" or any viewers. Basically, files with the extension .rock. They do NOT show up in the main menus, with one exception (the credits plugin).

You seem to have confused it with the term "patch".

Ah -- you're correct.  I was thinking of "plugins" and "patches" synonymously.  That said, a plugin would still reside on the Rockbox itself, and allow users to completely achieve article free sorting without needing anything else other than the actual Rockboxed unit.

And I don't believe Rockbox should ever be forced to restrict or limit itself for fear of offending other programs that don't adhere to standards. "Fear of incompatibility" is silly, if that incompatibility is with a program that doesn't support a standard it purports to.

It's not Rockbox I'd be worried about.  My concern would be potential complatibility issues between the other program used for editing these tags, and the user's audio management program of choice.  Again, these issues are 100% eliminated if the Rockbox itself took care of this task.

Larry

[Llorean]

If the user's audio management program supported the tagging specification properly, then where would the problem be exactly?

Not to mention, you don't have to run the program against your PC-side files. Just point it at the files on the device, click "go", and X minutes later the files on your device have their new, 100% legal according to specifications, tags. And much, much faster than it would take the device itself to update these tags by way of a plugin.

[soap]

It's not Rockbox I'd be worried about.  My concern would be potential complatibility issues between the other program used for editing these tags, and the user's audio management program of choice.  Again, these issues are 100% eliminated if the Rockbox itself took care of this task.

No, these issues are not eliminated if Rockbox itself took care of said task.
A pluggin (in said example) is "the other program".
There would be no difference in the files be it a PC app or a Rockbox app (pluggin) that does the tagging.  The "risk" is exactly the same.

Editing these tags outside of Rockbox requires a program that can see and edit these tags, and it requires a script made specifically to do this.

Editing these tags inside of Rockbox requires a program (the plugin) that can see and edit these tags, and it requires a script something made specifically to do this.

[lalittle]

No, these issues are not eliminated if Rockbox itself took care of said task.
A pluggin (in said example) is "the other program".
There would be no difference in the files be it a PC app or a Rockbox app (pluggin) that does the tagging.  The "risk" is exactly the same.

We're still not on the same page here.  The issues that I'm referring to are eliminated if the Rockbox takes care of this duty because the original files on the PC are untouched by the process.  Only the files already on the Rockbox are re-written, while the origian copies of these files on the computer remain exactly the same, completely "unaware" of the sort tags since these tags were not added until after the files were synced to the handheld.

Editing these tags inside of Rockbox requires a program (the plugin) that can see and edit these tags, and it requires a script something made specifically to do this.

Yes, but the distinction is that it happens within the Rockboxed unit.  No other external applications are necessary.  In other words, everything the Rockbox needs to achieve article-free sorting would be on the Rockbox itself.  No third party programs would need to be installed, configured, and utilized.  I'm simply advocating the idea that offering this "full service" capability on the Rockbox itself is an attractive feature to users like myself, and I believe that this would make the sorting feature more widely accessible.

Larry

[GodEater]

We're still not on the same page here.  The issues that I'm referring to are eliminated if the Rockbox takes care of this duty because the original files on the PC are untouched by the process.  Only the files already on the Rockbox are re-written, while the origian copies of these files on the computer remain exactly the same, completely "unaware" of the sort tags since these tags were not added until after the files were synced to the handheld.

Again, you're not getting it. If you plug your rockbox DAP into your PC - it becomes a drive letter. You point your tagging app at it, say tag these files here please. At no point then are your "original" files touched during the tagging process. At the end of the process, you unplug your DAP. You can even un-install the tagging app used. Your original files are still virgin, untouched on your PC's hard disk.

[lalittle]

Again, you're not getting it. If you plug your rockbox DAP into your PC - it becomes a drive letter. You point your tagging app at it, say tag these files here please. At no point then are your "original" files touched during the tagging process. At the end of the process, you unplug your DAP. You can even un-install the tagging app used. Your original files are still virgin, untouched on your PC's hard disk.

AH!  You're right -- I was misunderstanding.   Now I get what you're saying.

Yes -- pointing the application at the handheld's drive would indeed eliminate this particular issue (as would having this done entirely "within" the Rockbox via a plugin.)

I guess this comes back to the general work-flow concept -- the idea of whether you do this entirely from within Rockbox, or with an external program.  Personally, I still prefer the idea of having the capability of doing the entire process on the Rockbox unit itself.  I like the idea of it being entirely self-contained, and not requiring another application.  To me, even if it takes longer to do it this way, it actually simplifies the process.

On a related note, would the re-writing of the files with the new tags cause any issues with the database, or does the database simply rely on the folder/name of the file?

Thanks again for the clarification, as well as the discussion in general.

Larry

[Llorean]

Both doing it in Rockbox or on with an external app would require you to re-initialize the database. It can't use the sort tags until it's included them in the database, and the database doesn't support updating tags on existing entries.

[jurrie]

After having read the entire thread today I would like to add the following points/observations:

• The database feature is inherently dependent upon the data associated with (and by way of tags, provided by) the content supplied by the user.  The database purist would point out that if you want to use the database you need to populate it with proper data, and; if you're not willing to provide meaningful data then you shouldn't use the database (or expect it to be accurate).  Having come from a DAP which provides content navigation exclusively through a tag-fed database, this seems second nature to me.
  
  Realizing that not everyone is willing to ensure accurate data content and that these same users expect full database capabilities, some have suggested utilizing Rockbox's plugin capability to bridge that gap.  While the intent seems noble, there are issues with some of the implementation suggestions, which leads to....
  
  
• Suggestions have been made in this thread that "there should be a Rockbox plugin to add sorting tags to audio content which falls into certain categories" (i.e. add sorting tags for artist, album, title content which contain leading articles).  Rockbox is DAP (or DMP, if you prefer) firmware, where the 'P' stands for "Player".  As such, I would argue that this MysteryPlugin should not alter the player's content in any way.  A more appropriate solution would appear to be that the MysteryPlugin would instruct Rockbox's database (via some new API) to update the sorting attributes associated with selected content.
  
  This suggestion would yield the following benefits:
  
  • media content is unaltered
  • more efficient (reading/writing large content files could be expensive, both in terms of CPU and power)
  • the database wouldn't have to be completely rebuilt; only selected entries are updated
  • plugin actions (possibly faulty) could easily be undone by regenerating the database
  
  
  and the following cons:
  
  • if the database is rebuilt, sorting information would be lost, hence the plugin would have to be re-run

Please note that the plugin could interfere with sorting attributes previously associated with (provided by) the content.  The database's "update sorting attribute" API may wish to have a "force" parameter to override previous associations.  Similarly, one may envision a database setting which would prevent explicit sorting settings from being overwritten.

Edit: include cons

[lalittle]

I would argue that this MysteryPlugin should not alter the player's content in any way.  A more appropriate solution would appear to be that the MysteryPlugin would instruct Rockbox's database (via some new API) to update the sorting attributes associated with selected content.

Forgive me, but I'm unclear what this means.  How does it "update the sorting attributes"?  Could you clarify the details on what the process would involve?  I agree that it seems like a better idea to not alter the files, but I'm unclear how your suggestion would work.

Thanks,

larry

[Llorean]

I don't understand how it's a better idea not updating the files?

Better in what sense: Surely the files on your device aren't the primary copy of your music collection. That's generally a bad enough idea that you shouldn't be using an alternate firmware in the first place. Meanwhile, altering the files on the device allows the tags to be used by other programs (as there are programs that do support them), and insures that should you need to re-initialize the database you won't have to re-run the plugin.

The only advantage updating the database alone offers is "not having to change the files" which, in the end, isn't a very significant advantage. It just means that the information isn't available to any other part of Rockbox, or any tool that you use on your computer to keep your player in sync (or play your music, if you use your DAP as an external HD and play it with a PC tool to save battery in the case of those DAPs where this works).