Closed indeplaner closed 2 months ago
Yes, you are absolutely right. For now, TuneScape has full connection restoration and error handling for servers. The next step is to restore the playing station, like you mentioned. It can be difficult for some situations.
This is the next enhancement for TuneScape.
I'm glad you already understood my brief explanation. Broadcast servers don't always behave well in collaboration with TuneScape. Streaming, in my case from IceCast, was shutdown after some time!!
Any idea when you can release the planned "IceCast status bar"?
Do you mean connection status?
That's right, maybe in a pop up overlay window?
FYI: the announcement of an upcoming "I-C station" shutdown may be relevant to you.
As shown: the usual stream is halved. The sound is still there.
The opposite also happens at IceCast stations and now only updates the titles.
As shown: after a manual restart the sound is gone and it's a halved stream it seems. In this case streaming an Icecast station 256kbps, only updates of titles.
In the case of the stability of the network or station, TuneScape is not responsible for this. This is the third part of the application. The status of the connection is in the left corner for now.
The main problem is to what point the Qt internal implementation accepts weak network connections, its stability, etc., and this directly affects when the application must react.
I have some ideas on how to solve some problems. But this takes time.
TuneScape will be clear and minimal.
For now, I am working on notifications. Tests take time.
Can you give me some clarity on the technical question below. My thanks in advance.
In rare cases the sound wants to hang. A reboot of my PC is then necessary. Is the cause of this the streaming or rather the defective FFmpeg codecs?
I am testing TuneScape on different systems, which were freshly installed and never crashed, and on my personal PC too. There are many things that can go wrong.
Now I don't know if you should address this. Is this within your reach?
Nothing ever goes wrong when playing MP3, as far as I can see. But I see strange things with the CPU load on the "I-C stations with AAC". A huge stream will slow down the entire system and even a crash will be inevitable. I have already experienced this myself. I'm testing on an I7, 3.2 Ghz, 32GB of memory.
MHO: This can become a serious problem. Only 1 of the 12 logical processors is used, with decoding I suspect. Are those AAC codecs of FFmpeg completely stable?
Can I test here something myself in a standard way? Or should I start a new issue.
I think it can be valuable when you find a solution. Some other users can have the same problem. I tested it on a station with an AAC codec, and I don't have this problem. The application is stable.
Can you tell me which OS you are testing on? At the moment I'm on Win 10. I ask because the problem may only occur in Win 10 and 11.
This would also indicate a search direction for me.
I just looked into the event with the consciously serious problem. After repeating the AAC test, the same thing happens with CPU load. The load increases from 0.4% to 12.0% and a logical processor is almost fully loaded (4.6GHz)!!
Who sees through what is happening here? I noticed all of the following again in the latest "128kbps AAC test".
Windows Task Manager shows me that CPU usage increased from ±0.4% to 12.0% in 2 hours and 5 minutes. By loading just one logical processor, it increased almost to the max 4.6GHz!! It is possible to provide you with more figures, but that won't change much. I noticed, the background process management for Universal Windows Platform apps is involved at the start. And now I get the stupid feeling that the systems management is intervening in this all.
MHO: An optimization of the apps use of system resources is eligible. But that's only for you to judge, that's not up to me.
You are right; at some point, in Windows with ACC codecs, there are problems. But for now, I don't see any solution when, with others, it doesn't. Windows 10 22H2.
I will focus on these tests.
A short test showed that:
The first MPEG station stopped after a few minutes. TuneScape halved it's streaming. Only a restart of the app can make music streaming possible again. Otherwise something is going wrong in Windows memory.
The famous AAC incident is still the same. It always only happens after 2 hrs of use!! Please keep me posted.
After many tests, the results so far are as follows:
Windows 11 works correctly. I did many test cases to crash the app, and it worked correctly.
In Windows 10, there is evidently a problem when the system is asleep, hibarnate. When the system wakes up, the app uses more resources (processors) and does,t play. When the stream is closed, everything goes back to the correct way. I have suspicions about codecs as well.
I will have to look into it.
Well, your app just keeps playing for me, a good thing. My PC knows no hibernate mode, disabled it a long time ago. So no, there should be no hiberfil.sys on my drive. Or some virus should create this, in all this MPEG playing.
I hope this isn't a disappointment. Where should we look next?
There's no hibernate mode on my PC, I disabled it long ago. Your app simply keep playing in the case in question. That's certainly a good thing!
Now the app always runs without a sound hardware buffer present, if I remember correctly. So it plays on the speakers of my monitor.
Can you tell me, can this software sound buffer have any influence in the app?
Is it also possible that some information, at GitHub or SourceForge, will be revealed about upcoming improvements? That would be nice for many.
A new TuneScape v4.0.4 in use, I noticed changes have been made. I tested an AAC-station. Suddenly the music stopped, streaming is still 100%. Again only titles shown. The error log is telling me: 'No news'.
I decided to start my own test:
It depends on you now.
I need to correct something. For the first, I explained that I create streams independently to do their tasks correctly. The titles work behind the scenes so the user can get information about the author, podcast, or something else. If they want, push play and listen. And this is an important moment, I think, for you. {The app's playing stream only stops, crashes, and so on}. This is the playing stream. I use the most simple implementation for playing streams to avoid problems. For my tested physical machine Win10, I have any problems, so I don't know what I should do. When I squize requirements in VM on WIn10, then the TuneScape sometimes crashes, but this is normal.
The error log: this contains only the player log, lack of resources... For other errors, I will create separate files.
Points 3 and 4. And we are in the same situation. In my tested Mashine, all work correctly. The stream must stop when the connection is restored. I programmed it intentionally, but only for now. I can change it, and I don't understand why your PC crashed.
When it comes to the information, yes, I know, and I should do it. Ok, I will create some maps of bugs, improvements, and so on.
P.S. This is motivating.
Does a VM recognize a buffer underrun in an app?? I highly doubt about that. But I've never run such a test in a VM. I can't see exactly, what your testing in. But did you run a Win10 test, without using that hibernate mode?
Something intervenes between points 3 and 4 that causes the PC to crash; The 'cracking' sound was silenced
I just made some changes to an existing WiFi setting. This is a strange thing, a so-called Virtual Ethernet Adapter. Now I noticed an initial improvement when I stopped my WiFi. The app stayed alive and well!!
Now I'm going to run some more tests.
As it stands now, the crash is a thing of the past. That feels like a relief. I have posted some information on GitHub. As well as a request regarding safety!!
https://github.com/grzesiekkedzior/TuneScape/issues/8#issue-2351254567
Op wo 12 jun 2024 23:02 schreef Grzegorz Kędzior @.***>:
I need to correct something. For the first, I explained that I create streams independently to do their tasks correctly. The titles work behind the scenes so the user can get information about the author, podcast, or something else. If they want, push play and listen. And this is an important moment, I think, for you. {The app's playing stream only stops, crashes, and so on}. This is the playing stream. I use the most simple implementation for playing streams to avoid problems. For my tested physical machine Win10, I have any problems, so I don't know what I should do. When I squize requirements in VM on WIn10, then the TuneScape sometimes crashes, but this is normal.
The error log: this contains only the player log, lack of resources... For other errors, I will create separate files.
Points 3 and 4. And we are in the same situation. In my tested Mashine, all work correctly. The stream must stop when the connection is restored. I programmed it intentionally, but only for now. I can change it, and I don't understand why your PC crashed.
When it comes to the information, yes, I know, and I should do it. Ok, I will create some maps of bugs, improvements, and so on.
P.S. This is motivating.
— Reply to this email directly, view it on GitHub https://github.com/grzesiekkedzior/TuneScape/issues/7#issuecomment-2163894809, or unsubscribe https://github.com/notifications/unsubscribe-auth/BI5FZAB6CXMW2PXAPERINADZHCZORAVCNFSM6AAAAABIYXYXN6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTHA4TIOBQHE . You are receiving this because you authored the thread.Message ID: @.***>
I am happy that we ended this battle with success.
I am happy that we ended this battle with success.
I'm glad it was a good result and a great learning moment for both of us.
Any idea who of your speudo 'colleagues' is kicking participants out of the Net?? In all the cases when there has been a post on GitHub. Some people out there are annoying for fun!!
KEYBOARD KNIGHTS THAT DON'T HAVE ANY BETTER TO DO THEN FIGHT IMAGINARY DRAGONS!!
I need to correct something. For the first, I explained that I create streams independently to do their tasks correctly. The titles work behind the scenes so the user can get information about the author, podcast, or something else. If they want, push play and listen. And this is an important moment, I think, for you. {The app's playing stream only stops, crashes, and so on}. This is the playing stream. I use the most simple implementation for playing streams to avoid problems. For my tested physical machine Win10, I have any problems, so I don't know what I should do. When I squize requirements in VM on WIn10, then the TuneScape sometimes crashes, but this is normal.
The error log: this contains only the player log, lack of resources... For other errors, I will create separate files.
Points 3 and 4. And we are in the same situation. In my tested Mashine, all work correctly. The stream must stop when the connection is restored. I programmed it intentionally, but only for now. I can change it, and I don't understand why your PC crashed.
When it comes to the information, yes, I know, and I should do it. Ok, I will create some maps of bugs, improvements, and so on.
P.S. This is motivating.
Points 3 and 4, do you mean: 'The stream must stop', or playing must stop, so no sound? In any way the stream is still 100% and the station is in the air!! There's no sound available for me.
Perhaps if there's any explanation, it will fall into place now . Thank you!
It is more common that in the evening all internet servers are fully occupied. It happens now that there are stations who don't request feedback in their streaming.
If everything slows down, I see the usual stream being cut in half. So far everything continues to work "as usual". When everything on the internet gets worse, streaming is suddenly broken off. All that remains is the sound of silence....
Is there any possibility that after 3-5 sec of silence the stream will be restarted by TuneScape? That's no walk in the park, to improve this, I know.