search

tramhao / termusic

Music Player TUI written in Rust
GNU General Public License v3.0
1.05k stars 44 forks source link

rusty backend network stream never clear buffer files and grow indefinitely #238

Closed hasezoey closed 6 months ago

hasezoey commented 6 months ago

I noticed that when using networks streams, the stream is buffered in a /tmp file, but that file keeps growing indefinitely, and after playing ~15 minutes it has grown to ~14Mb, even though it is not seekable (and the stream is not paused). For context this is a live radio, so it will never end.

i know this is not really significant for this size yet, but still it never gets cleared and for machines which run ~8 hours or even a day, this could quickly grow to gigabytes of unused data.

termusic 07e6a7f971b69368751d57818bb3e4838ad4f6e8

Should we refactor indefinite network streams to not buffer to files and instead use some kind of in-memory buffer? (i am not sure which would be the best, ring buffers maybe?)

tramhao commented 6 months ago

Could be. I have no experience in ring buffer. Please go ahead and try to fix it. Thanks!

tramhao commented 6 months ago

I saw that stream-download.rs updated a lot. Perhaps the upstream fix the problem.

hasezoey commented 6 months ago

if upstream is this stream-download, then yes, it looks wholly different than our version, but in turn this would also mean completely re-implementing radio download as we patched in our own radio title handling (also see #242)

hasezoey commented 6 months ago

just for reference:

$ ls -al .termusic-stream-cache-GzYcpR
-rw------- 1 hasezoey hasezoey 30664411 Mar 18 16:45 .termusic-stream-cache-GzYcpR
$ ffprobe .termusic-stream-cache-GzYcpR
[mp3 @ 0x63f02a8c3940] Estimating duration from bitrate, this may be inaccurate
Input #0, mp3, from '.termusic-stream-cache-GzYcpR':
  Duration: 00:31:56.53, start: 0.000000, bitrate: 127 kb/s
  Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 128 kb/s
tramhao commented 6 months ago

https://github.com/aschey/stream-download-rs/blob/main/examples/from_stream.rs

From the above example, seems that they can parse header now. Maybe we can use them directly, without parsing the header resulted in 2 streams.

tramhao commented 6 months ago

I have a working version in dev branch. Would you please check if the problem is solved?

hasezoey commented 6 months ago

with the current dev branch (bd30f74d2e1e63b70c85d106a9021ef1afa7c28f & a84b0c59e414965aeab85824a3c7287ae1dd4f27) it works and there are no temporary stream files anymore, so yes this issue is fixed.

though quite like how a new tokio runtime is created there, we should likely just pass a handle to the existing one down.

PS: sorry, this is edited, i thought this was a different issue, i thought this was #242

tramhao commented 6 months ago

I found seeking is not working for podcasts, which used to work. problem.

hasezoey commented 6 months ago

I found seeking is not working for podcasts, which used to work. problem.

is https://github.com/aschey/stream-download-rs/issues/27 related?

tramhao commented 6 months ago

No, the problem is the input of symphonia decoder should be mediasource, but stream-download didn't implement this interface(which I implemented before in local stream-download).