[BUG] Simple Play example doesn't quit after playing finishes

[digfish]

Describe the bug
Hi, I tried your library using a simple example

To Reproduce
Steps to reproduce the behavior:
On VS Code 1.78.2 i run The following snippet:

    zeroconf = ZeroconfServer.Builder().create()
    session = Session.Builder() \
        .user_pass("myusername", "mypassword") \
        .create()
    access_token = session.tokens().get("playlist-read")
    track_id = TrackId.from_uri("spotify:track:6UCFZ9ZOFRxK8oak7MdPZu")
    stream = session.content_feeder().load(track_id, VorbisOnlyAudioQuality(AudioQuality.VERY_HIGH), False, None)

    ffplay = subprocess.Popen(
        ["ffplay", "-autoexit", "-"],
        stdin=subprocess.PIPE,
        stdout=subprocess.DEVNULL,
        stderr=subprocess.DEVNULL,
    )

    ended = False
    while ended !=True:
        if ended : print("ended")
        bytes = stream.input_stream.stream().read(256)
        sent = ffplay.stdin.write(bytes)
        if sent == 0:
            logging.info("0 bytes sent!")
            ended = True

Expected behavior
FFplay pops out and starts playing the track until the end after that exits cleanly but the program is stuck. I'm only able to stop pressing the trash button to kill terminal pane on vscode or killing it manually in the task manager. Doesn't respond to Ctrl+C

Screenshots
Last lines of output:

DEBUG:Librespot:Session:Chunk 8/8 completed, cached: False, stream: file_id: 6dba450723dfdf967aa3740beeca4d73adde7bca
INFO:root:0 bytes sent!

Client Information (please complete the following information):

• OS: Windows 10 22H2
• Python Version miniconda v 3.10.4
• Library Version 0.0.9

Additional context
Add any other context about the problem here.

[kokarare1212]

I can't confirm such a phenomenon with Python 3.10.10 on Windows, though, I think it will end correctly if session.close() is executed at the end.

[digfish]

Hi, thanks for you reply, I tried to add: ``` session.close() ``` but now the remote server drops the connection suddenly, like the error reports: ``` INFO:Librespot:Session:Closing session. device_id: 9911b430490141c432082c879310aa7a852de101 INFO:Librespot:Session:Closed session. device_id: 9911b430490141c432082c879310aa7a852de101 Exception in thread session-packet-receiver: Traceback (most recent call last): File "E:\Miniconda\lib\threading.py", line 1009, in _bootstrap_inner self.run() File "E:\Miniconda\lib\threading.py", line 946, in run self._target(*self._args, **self._kwargs) File "E:\Miniconda\lib\site-packages\librespot\core.py", line 1674, in run packet = self.__session.cipher_pair.receive_encoded( File "E:\Miniconda\lib\site-packages\librespot\crypto.py", line 58, in receive_encoded header_bytes = self.__receive_cipher.decrypt(connection.read(3)) File "E:\Miniconda\lib\site-packages\librespot\core.py", line 1578, in read return self.__socket.recv(length) ConnectionAbortedError: [WinError 10053] Uma ligação estabelecida foi anulada pelo software no computador anfitrião ``` and even after this in the end the program continues in getting stuck... ! 2023-06-03 23:46 GMT+01:00, 碧舞すみほ ***@***.***>:

…

I can't confirm such a phenomenon with Python 3.10.10 on Windows, though, I think it will end correctly if session.close() is executed at the end. -- Reply to this email directly or view it on GitHub: #200 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[benearnthof]

Hi, I am currently facing the same problem on a windows machine when trying to stream audio from a list of URIs. Even after adding session.close() it leads to the error message. This does not impair my usage at this time since I'm only using the audiostream to extract a transcription but adds a lot of clutter to the console output & a bit of confusion on my part.

[cvdub]

I believe I fixed this with #300