• 1(current)
  • 2
  • 3
  • 4
  • 5
  • 11
[split] Improved Classical Music Browsing
#1
This thread splits from a (historic) feature request here http://forum.kodi.tv/showthread.php?tid=275796

The discussion of what I implemented continues here....

Thanks to Zag there is now a test build (for windows) of my initial work. It is here http://mirrors.kodi.tv/test-builds/win32...tRoles.exe See nightlies for builds that include this work.

It is difficult to catch users attention (all off living their lives), but it would be great if some of you could test this out and feedback.

The initial improvement is having Kodi process COMPOSER (TCOM), CONDUCTOR (TPE3) and ENSEMBLE tags and have them appear in the artists list. Then rather than list artists as a jumble of these roles you can list just composers, conductors or orchestras separately.

To see the new functionality you need to have approriately tagged music files and create some custom nodes. It is only a first step so don't expect too much, more to come.

Tagging: If not already set, add COMPOSER (TCOM), CONDUCTOR (TPE3) and Ensemble tags (some of these or all 3). These artists may also be included in the ARTIST or ALBUMARTIST tags, that is fine if they are but do use the same spelling. For example

Artist: Antonín Dvořák / Scottish National Orchestra / Neeme Järvi
AlbumArtist: Antonín Dvořák
Composer: Antonín Dvořák
Conductor: Neeme Järvi
Ensemble: Scottish National Orchestra

Create some custom nodes, that is xml files as follows in the userdata/library/music folder
Code:
<?xml version='1.0' encoding='UTF-8'?>
<node order="6" type="folder">
    <label>Test Composers</label>
      <icon>DefaultMusicGenres.png</icon>
    <path>musicdb://genres/-1/?roleid=3</path>
</node>

<?xml version='1.0' encoding='UTF-8'?>
<node order="6" type="folder">
    <label>Test Conductors</label>
      <icon>DefaultMusicGenres.png</icon>
    <path>musicdb://genres/-1/?roleid=4</path>
</node>

<?xml version='1.0' encoding='UTF-8'?>
<node order="6" type="folder">
    <label>Test Orchestras</label>
      <icon>DefaultMusicGenres.png</icon>
    <path>musicdb://genres/-1/?roleid=5</path>
</node>

Brief instructions, but hopefully enough.
Reply
#2
Tested and works well creating a standard composer tag using mp3tag

Can you explain this bit? <path>musicdb://genres/-1/?roleid=3</path>

Can it be improved to <content>composers</content> ?

Image

NOTE:

You can also use the Library Node Editor Add-on to play around with custom nodes. Its much easier than editing XML files but I think it needs to be updated for the new tags...

http://addons.kodi.tv/show/plugin.library.node.editor/
Reply
#3
Thanks for having a go Zag, the usefulness of this change only comes into its own when you have a big classical music collection of course. Hope someone like that spots this!

(2015-09-17, 13:40)zag Wrote: Can you explain this bit? <path>musicdb://genres/-1/?roleid=3</path>

Can it be improved to <content>composers</content> ?

Sorry about the ugliness of that line, I was just trying to have minimum impact on the established interface to folder type custom nodes, and still get something working. But i take your point, it doesn't look user friendly.

I like the folder type nodes, rather than smart playlist kind, they use more efficient queries and offer a "*all" item that takes you to the next level in artist>albums>songs. To unpack that line a little:

<path>musicdb://genres</path> is a standard internal path used for opening dialogs/windows, documented here

<path>musicdb://genres/6/-1/?genreid=6</path> gives you the albums with songs with genre with id = 6. Found that by trial and error, and debug on the code.

<path>musicdb://genres/6/</path> gives you artists with songs with genre with id = 6. And so on.

So I extened the internal path parsing to process roleid in the same way as it does genre, album or artist id.

I agree <content>composers</content> looks much more user friendly, but will take more changes to internal path processing and a bigger step than was sensible at this stage. The other user friendly approach is to provide the classical music xml menu structure as an addon, then the user need not pay any attention to the ugliness.
Reply
#4
Thanks to all for working on this.

Since this is a "Feature Request" - does that mean kodi developers will consider implementing it in Kodi 16? I would have thought that all extended tags and custom tags should be supported, but specifically skipping composer seems unusual.
Reply
#5
Yes, if the code submitted is approved, it will be in Kodi 16

Thats the wonders of OpenSource Wink Anyone can contribute!
Reply
#6
Unfortunately my code contribution has not been approved yet (although nobody has found errors either), and apparently the merge window is now closed. Not quite sure what that means Zag, and thanks for your enthusiasm and support, but I presume my composer work is not going to be in 16.

S Bodi it is nice to know that there is another user interested in these improvements. But if you read through the forums you will soon realise that users wanting something does not mean it happens quickly or even happens at all. I am happily putting in the development work, which is a start, but it is yet to be seen if or when this will be available in the official version. It needs at least 2 Dev Team members to have the time, expertise and interest to check my work - both the coding standards and the fundamental design - to see if it is suitable, and be willing to sign it off. This is slow as the team members are busy people, and few have an interest in music let alone classical music. Also I am new and unknown, so it is going to take a while to gain credibility. How quickly this feature appears is largely beyond my control.

Oh Zag you make is sound so easy!!
Reply
#7
Next merge window will be 1 October and I'm sure it will go in. We save the last 10 days of the month for fixing stuff only.
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#8
Thanks Martijn. We are that near the end of month already, where did that go!
Reply
#9
1. Where is the new tag data being stored? I can't find it.
2. Any possibility of infolabels for these?

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Matrix see: Aeon MQ5 Mod Matrix release thread
Nexus see: Aeon MQ5 Mod Nexus release thread
Aeon MQ 5 skin and addon repo 11.1.0
Reply
#10
(2015-09-21, 21:24)DaveBlake Wrote: I am happily putting in the development work, which is a start, but it is yet to be seen if or when this will be available in the official version. It needs at least 2 Dev Team members to have the time, expertise and interest to check my work - both the coding standards and the fundamental design - to see if it is suitable, and be willing to sign it off. This is slow as the team members are busy people, and few have an interest in music let alone classical music. Also I am new and unknown, so it is going to take a while to gain credibility. How quickly this feature appears is largely beyond my control.

Oh Zag you make is sound so easy!!

Just to expand on what Martijn has said.

Merge window for changes/new features is the 1st of each month to midnight CET on the 20th of each month, from here to the end of the month is a stability period to allow for the finding of bugs introduced in the merge window just passed, note that fixes for bugs can be merged at anytime including this period at the end of the month.

Thus my suggested work flow is the raise PR before the end of the month with the target of getting it added in the next merge window. The earlier you do this gives more time for getting it reviewed, make any required changes, and get it into a state where it can go straight in on the 1st of the month or at least in the first few days. If the 1st of the month has come and it hasn't been reviewed now is the time to give people a slight nudge to ensure you have plenty of time to do changes, get it reviewed again if necessary, and then get it into a fit state for meger before the 20th.
Reply
#11
Just a quick +1 for interest in this, and looking forward to the new version!

thanks all for the work,
Reply
#12
(2015-09-22, 02:01)scott967 Wrote: 1. Where is the new tag data being stored? I can't find it.
2. Any possibility of infolabels for these?
Thanks for your interest.

I am refering to the tag data in the music files themselves .The tags are standard to ID3 and Flac/Vorbis just Kodi has never processed them before. If you did not already set these tags, and you may not given Kodi didn't use them, then it is a matter of using a tag editor. Again I can give more info, just not sure what level to pitch my answer.

I will have a look at infolables. This was just a first step it what could be a long road. Tried to keep it as simple as possible for the devs to review, but it does mean it doesn't offer the user a great deal yet.
Reply
#13
Yep see this post for lots of new tags that could be integrated in the future Smile

http://forum.kodi.tv/showthread.php?tid=239637
Reply
#14
Not sure why this thread is now marked solved, it is far from it!!!!

Zag was it your post that labelled it? Could you change it back?
Reply
#15
changed it back
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
  • 1(current)
  • 2
  • 3
  • 4
  • 5
  • 11

Logout Mark Read Team Forum Stats Members Help
[split] Improved Classical Music Browsing3