Idea about Infinite Playlist

[J D]

I've been using the BubbleUPnP app and server to cast my local music collection of over 2,000 songs to my OpenHome speaker. I've noticed that creating and casting a large playlist can take a significant amount of time, sometimes up to 10 seconds. This has led me to think about a new way to handle playlist management.

My core idea is to implement an "infinite playlist" by shifting playlist generation from the BubbleUPnP app to the BubbleUPnP server.

How the Concept Would Work

1. Partial Playlist Generation: Instead of sending a complete, massive playlist, the BubbleUPnP server would generate a smaller, more manageable playlist (e.g., 200 songs). This smaller list would be sent to the OpenHome speaker, allowing playback to begin almost instantly.

2. Chaining Playlists: The playlist file itself would be structured to reference the next playlist in the sequence, similar to how the HLS (HTTP Live Streaming) protocol works.

3. On-Demand Loading: When the speaker reaches the end of the current playlist, it would automatically request the next "chunk" of songs from the server.

This approach would prevent long initial loading times and would allow for a seemingly endless playlist experience without the need to manage a single, gigantic file.

What are your thoughts on this idea? Could this be a viable way to improve performance for large music collections?

[J D]

Amends:

I mentioned it took 10 seconds, but in fact only less than 50 songs being added as result.

Try to add 4k songs to playlist, the process took maybe one minute then timeout.

Current implementation handle large playlist badly, please consider improvement.

[SimBun]

Given that you don't mind having a dependency on the app, why don't you just play to the non-OpenHome renderer - assuming you're only using Server to add OpenHome?

[SimBun]

Sorry I think I may have answered the wrong question.

Do you have an OpenHome renderer? What function is BubbleUPnP Server performing in this context?

I use BubbleUPnP Server to proxy UPnP renderers and the only delay I've experinced is when sending the playlist between app and server, but you seem to be implying a secondary delay between server and renderer.

[J D]

My setup involves a few key components:

• Speakers: A Sony HT-Z9F and an SRS-X88, which are DLNA compatible but not OpenHome.

• Media Server: MinimServer, which hosts my music library.

• BubbleUPnP Server: This is the crucial part. It acts as a proxy, creating an OpenHome renderer for my Sony speakers. I use this proxy because the speakers' native DLNA compatibility is unreliable, and I need more gapless and random looping playback functionality.

• BubbleUPnP App: This acts as the control point. It reads music from MinimServer and sends the playlist to the OpenHome proxy created by the BubbleUPnP Server.

The problem is the significant delay and timeouts when I try to send a very large playlist (thousands of songs) to the speakers.

I dont know there these delays and timeouts come from app-server or server-renderer communication, but I assume break these play all large list into small batches can be more optimized with performance.

[SimBun]

That's the configuration I assumed initially.

The delay is between app and server as your speakers can't handle queues (just current and next).

It might be possible for the app to page the items to the server in order to reduce playback delay (though "loading" duration would be the same); that or you could just send it directly to the speakers - though this would require the BubbleUPnP app to orchestrate playback.

[J D]

So... For now I could just add by small batches or pages my self? it would take a lot effort.

Maybe I need a more packed solution, with media hosting, playlist, and openhome casting into one server, eliminates delays.

[Bubblesoft]

Hi,

With an OpenHome renderer, whenever you add a track to the playback queue (in Android BubbleUPnP, the content of the Playlist tab) a http request is made to the renderer

(here BubbleUPnP Server acting as OpenHome renderer for your Sony renderer). 

This is rather inefficient and slow as you noticed, and was never designed for large playback queues. It is missing a bulk mode were you could add, say, 100 tracks at a time,

but the protocol is what it is and we cannot modify it.

It's been some time I have not benchmarked BubbleUPnP Server OpemHome track insertion speed and will have a look to check if something is slower than it could be.

But adding hundreds or thousands of tracks will still be slow.

The people that designed the OpenHome protocol (Linn) never intended for the OpenHome playback queue to hold an entire music collection or thousands of tracks. It was for less than 100 tracks for most use cases (a few albums) and their hardware had a limit to 1000 tracks maximum.

[J D]

Thank you for your detailed explanation.

Maybe I need a more media server centered solution, as passing large collection of songs is not viable.

[Bubblesoft]

There is still a possible middle ground.

In BubbleUPnP you can generate "random tracks" and "random albums" playlists

where you get to choose the number of tracks and albums respectively.

That functionality is found in the Library tab, entering the "Random tracks" and "Random albums" folder.

Simply use these folders to generate a random list of items of reasonable size and add them to the Playlist tab.