Prevent memory leaks by cleaning up playlist listeners

[Borewit]

Ths PR improves the de-registration of playlist listeners, to prevent memory leaks.

Although at various places the life-cycle management of playlist listeners improves, as well duplicate playlists lists has been removed, playlists are still being present in memory after closure of the playlist. It looks like at least a Future of the SwingWorker, which loads the playlist in the background keeps a reference to the playlist, preventing the garbage collector from cleaning it. I could not find a method to clear the Future or the SwingWorker. As the number of SwingWorker are limited as they are rotated from a pool, I assume the leak is limited.

May have resolved #219

[github-actions]

Build run (#6442603706, attempt #1) artifacts

[touwys]

Build run (#6442603706, attempt #1) artifacts

👉🏻 Should I be testing this build?

---

Additional information pertaining to the memory usage of this particular build:

1. Build:

   

2. It appears that it is not so much a memory issue, as one of the CPU: Almost throughout the complete playlist repair process, listFix() will grab hold of 98-100% of the CPU processing power. It uses c. 39% RAM:

   

3. CPU Specs:

   

[touwys]

@Borewit

About the aforesaid post:

I cannot remember that the excessive CPU-usage was ever an issue before — even on the ancient PC. The available CPU-processing power and physical memory coped rather well with the job at hand. Can you think of anything that could've changed that state of affairs? More importantly, do you think it can be fixed, or improved upon?

[Borewit]

👉🏻 Should I be testing this build?

Yes that is useful, if it does not break anything it good to go.

I cannot remember that the excessive CPU-usage was ever an issue before

That has been introduced in #203, when we enabled parallel processing. It uses nearly uses all CPU power available to get the job done, which should not be an issue.