[BUG] Simple Play example doesn't quit after playing finishes
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.
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.
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: https://github.com/kokarare1212/librespot-python/issues/200#issuecomment-1575241643 You are receiving this because you authored the thread.
Message ID: @.***>
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.
I believe I fixed this with #300