[Ned Scott]

Another use case that I think is valid:

I haven't done this in a while, but there was one year where I loaded only christmas music into an XBMC music library from a thumb drive. What people want to listen to in the living room for parties or events might not be their entire collection. It might be just the stuff that makes sense to play from the HTPC. I don't even have my entire music library connected to a network share for this very reason.

Removing the songs node just seems very short sighted to me. If it bothers anyone then they can edit their own nodes. That's why that ability is there, after all.

[Powerhouse]

I agree with jjd-uk, in that I like the feature, but if you have a large Music library (which I do), this can take a long time to populate (and initial playback of a selected song can be very slow). Perhaps leave this feature, but have a dialog box pop up saying:

Please Note: If you have a large Music Library, this may take several minutes (or longer) to populate this list. Are you sure you wish to continue? Yes, No.

[jjd-uk]

The question for me is what on does Kodi do to make it so slow opening a full Song listing for playback? My 10 year old ipod classic has no problem doing random playback on a 30000+ track library.

[Powerhouse]

Ouch, feel that Sting, cause you just got Burned...

8)

[Powerhouse]

Ok that was Childish, but considering my Quad Core, 16Gigs of Ram, 512Gig SSD drive, takes a long time to display a list of Music Tracks, says to me, Kodi is doing stuff it shouldn't be.

[BobCratchett]

I think we have to take it as said in this thread that speed issues aren't the at the root of the desire to remove the songs node - and lets ignore what's said in the PR for that . The issue therefore becomes one of whether this option is useful to a significant number of users. The fact that there are multiple reports of users finding it slow would suggest that there are enough users for the node to be kept.

Having said all of that, it's already easy enough with the Library Node Editor addon to delete the songs node if its not wanted, and the Krypton version of the editor (which properly supports 'path' based nodes) will make it just as easy to add it back if the user does want it. That means a different argument can be made - based on the idea that those who edit nodes tend to be 'power users', as custom nodes are not generally known to less experienced or technical users.

With that being the case, and it being so easy to add or delete said node, if it's a feature that's primarily used by less experienced users - who will not know how to add the node if they want it - it should be kept. If it's a feature primary used by more experienced users - who will be able to re-add it if they want it - it should be deleted. Unfortunately, I don't know the breakdown of the experience of the users who do make use of it.

I also have to confess to being confused by the argument that it's about GUI space. It's generally displayed in a list that can show as many items as is necessary. Will removing one item lead to that much extra 'GUI space'...?

[DaveBlake]

I also have to confess to being confused by the argument that it's about GUI space. It's generally displayed in a list that can show as many items as is necessary. Will removing one item lead to that much extra 'GUI space'...?

In Estuary all the nodes/menus are displayed as an icon wall (although a list view option would be a nice addition) so maybe that is the GUI space issue? I don't get that either.

[ironic_monkey]

Sigh. It is so sad to see these discussions. *Somebody* using the node should be eod. It is 10 lines of code that hasnt changed since 2005. The underlying functions have to be there no matter for xsps. And one more item in the gui doesnt harm anyone or anything. Go 'contribute' to gnome or something.

[zag]

Thanks everyone, you have certainly convinced me. Its good to hear all the comments.

I do see a lot of room for improvement in this feature though.

EDIT: Just to clarify... nodes are editable by anyone these days, you can add, delete or modify them yourselves by editing the file below:

system/library/music/songs.xml

PHP Code:

-<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
 -<node order="5" type="filter" visible="Library.HasContent(Music)">
 -  <label>134</label>
 -  <icon>DefaultMusicSongs.png</icon>
 -  <content>songs</content>
 -</node> 


So if you wanted to delete the songs node yourself, just remove the above file from your Kodi install.

[Tolriq]

The question for me is what on does Kodi do to make it so slow opening a full Song listing for playback? My 10 year old ipod classic has no problem doing random playback on a 30000+ track library.

The question is bigger than that http://forum.kodi.tv/showthread.php?tid=196537 is I think the biggest problem.

Queuing a few songs no matter how is very slow. the problem is that I have no knowledge on debugging on rpi and on my main windows device all is too fast to find the culprit

[DaveBlake]

Sigh. It is so sad to see these discussions. *Somebody* using the node should be eod. It is 10 lines of code that hasnt changed since 2005. The underlying functions have to be there no matter for xsps. And one more item in the gui doesnt harm anyone or anything.

Yes, it makes me sigh too.

[DaveBlake]

The question for me is what on does Kodi do to make it so slow opening a full Song listing for playback? My 10 year old ipod classic has no problem doing random playback on a 30000+ track library.

From the litttle testing I have done, Razze has done more with same conclusion, the issue is the fundamental way we process every results dataset into a CFileItem list. The database query is quick enough, so the issue is not the DB, but what we do next. Transfering the entire dataset of many records into Kodi's internal memory before we display the first page of items is what is slow. But changing that heart of Kodi is no easy task.

[Tolriq]

It's slow but it's not the main reason.

You can see for example : http://forum.kodi.tv/showthread.php?tid=...pid1732610 that will queue 13 songs 1 by 1.
This will take 10 seconds.

You start the album that contains those 13 songs it's 1,5 seconds, the playlist contains the exact same amount of data, the same number of CFileItem containing the exact same set of data.

There's just a problem with queuing songs for a yet to be discovered reason.

[DaveBlake]

It's slow but it's not the main reason.

It really is the main reason why showing the songs node is slow.

There is some other problem with the delay in queuing songs, but no idea why it should get a mention here.

[NEOhidra]

Please keep it!