Fixes for ESP32

[tobiasguyer]

Adjusted main.cpp ro the new cspot structure. I took the cliPlayer as reference and changed as less as possible

[tobiasguyer]

So.. i think, i can call the current build stable enough, to be posted in here. There are still problems with seeking on cli and probaly esp's without vs1053. And i ran into some issues with some specific tracks(they bring the mercuryManager to fail in read, and after that, the esp resets, because of some switching issues, but i can't find the faulty declared function). And episodes do have no autoplay yet. But apart from that it runs smooth.
It changed structural quite a lot. I had to switch from spirc to connectState requests, because of information loss in spirc. And most of the other changes are for commits from my side.
And i tried my best with freeing all allocated memory.
If you think, it's too much of an alteration to still call it cspot, just take a peek at the new TrackReference functions, they solve my once intended ghostTrackList change quite smooth.
If you want to stay loyal to spirc, i could try to solve the issues of the memory-loss with my old commit. But the smart shuffle and radio functions are never gonna be properly displayed.
Regards tobi

[tobiasguyer]

So.. seeking was quite simple.. i've just missed a resetTrackPlayer.
I still have to adjust some things in mercuryManager.
I think MercuryTask has a little to less memory allocated. And the subscriptions seem to be not failsafe yet..

[tobiasguyer]

I'm sorry for that mess :) it's finally working quite good on cli and vs1053, the only problem i haven't resolved is, if there are only queued tracks in the playing-history ( for example after takeover of a list with queuedtracks), the normal shuffle expects it to be the end and switches to autoplay, and the autoplay of episodes.
apart from that i'm quite happy with my build.
i've solved some preloadedTracks issues in an ugly way.
but otherwise it runs smoothly for quite a long time ( it still quited after 200 tracks because of a httpRead error in cdnAudioFile. but i can't find the cause, and 10 hours of a continuos stream is quite satisfying)
regards tobi

[tobiasguyer]

So.. i had to take a small detour to feelfreelinux/bell since updating to espidf v5. Currently the bell repository is linked to my bell repository, because it handles quite a lot of errors issueing from mbedtls.

[tobiasguyer]

There are still a few issues that need attention:

1. Missread in TLSSocket: Currently, when a read error occurs in the TLSSocket (e.g., network failure or timeout), the TrackPlayer simply skips to the next song. However, it should be possible, to reconnect to the CDN or resend the request, continuing from where the failure happened, instead of skipping the track.

E TLSSocket.cpp:97: TLS read error (-34), retrying... Attempt 1
E TLSSocket.cpp:101: Read error with code -32

E HTTPClient.cpp:116: Underflow error during response reading: Buffer not available and yield failed
E TrackPlayer.cpp:288: An error has occured in the stream -1
I TrackPlayer.cpp:328: Playing done
D DeviceStateHandler.cpp:110: Ended track, needs_to_be_skipped = true
E TrackPlayer.cpp:137: new Track stream
E TrackPlayer.cpp:140: all good with stream

2. Playlist reshuffling with Classic Shuffle: When using the "classic shuffle" mode, if the playlist gets reshuffled, the player starts loading radio tracks. This seems to be a logical failure in the resolveContext function and should be solved with next update.