Tomcodon / practicesharp

Automatically exported from code.google.com/p/practicesharp
0 stars 0 forks source link

1.5.0 locks up, but 1.4.1 works perfectly #10

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.Download an MP3 podcast, for example 
http://downloads.bbc.co.uk/podcasts/radio4/iot/iot_20111208-1145a.mp3
2. Double click that podcast in Windows Explorer (this assumes you have 
associated MP3 with Practice#)

What is the expected output? What do you see instead?
File "opens" but does not "play". The program says it is playing (the pause 
button is available, the text at the bottom says Playing), but the MP3 does NOT 
play.

What version of the product are you using? On what operating system?
1.50 on Windows 7

Please provide any additional information below.
Copying the 1.41 executable over the 1.50 and retrying, then everything works 
normally.
I have had this problem since the day 1.50 was released and it appears I am the 
only person who does (or perhaps others downloaded 1.50 and had the same 
experience and just abandoned it). I was curious to see if you had a new 
release and it looks like you did but it was pulled back.  

I guess you have not been able to replicate this. I have no other problems with 
my PC. I will TRY to assess with PROCMON to see if it shows anything of note, 
but I just wanted to revive this issue as it still boggles me why it exhibits 
this behavior. I even tried uninstalling and removing every trace of the 
program and its registry entries and files and only installing 1.50 and that 
did not fix anything. 
Aside from this (meaning using 1.41) your program is unbelievably great. I just 
want to be able to use the latest version for the few tweaks and fixes it gives.

Original issue reported on code.google.com by kzinn...@gmail.com on 9 Feb 2013 at 12:00

GoogleCodeExporter commented 9 years ago
I see that issue 4 looks to be the same issue, not sure how I missed that 
earlier. 

I just tried something I had tried before (completely wipe all signs of P# and 
just install 1.50) and this time all tested MP3s start but a few seconds to a 
few minutes in to playback, P# locks up. 

You mentioned v1.51 .. is that available or should I wait patiently for the 
re-release of 1.60?

Original comment by kzinn...@gmail.com on 9 Feb 2013 at 12:29

GoogleCodeExporter commented 9 years ago
Thanks for posting this.
I cannot replicate it with this MP3.

Last week I had a lockup too with another file, or another machine (Windows 7 
too), and it does replicate.
That is why I froze the release of ver 1.6. On that machine the lock up 
happened on 1.5.1 as well.
I'm not sure what it is.
It could be a faulty logic (i.e. thread dead lock) or an issue with the 
underlying NAudio engine (maybe the different sound card?)

Anyway, I will investigate it and find a fix. Please be patient, it might take 
a few weeks. Sorry about the inconvenience. 

When I'll release it (soon) it will be ver 1.6.1.

Original comment by yuva...@gmail.com on 9 Feb 2013 at 3:44

GoogleCodeExporter commented 9 years ago
Issue 4 has been merged into this issue.

Original comment by yuva...@gmail.com on 9 Feb 2013 at 3:44

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
UPDATE
On one machine I have zero issues, as I mentioned (Windows 7 Pro 64 bit, Lenovo 
S30 with on board sound card)
But on another laptop (Windows 7 Pro 64 bit, Lenovo X230 with on board sound 
card, Real tek RTKVHD64.sys) I have a strange behavior which might be seen as a 
lock up - putting a debug breakpoint while running, or making the speed faster 
or other similar changes, cause an internal audio thread (non managed) to 
exit..!!??
In my code there is logic that selects Wasapi/DirectSound/WaveOut based on the 
OS.
The older versions of PracticeSharp used DirectSound. But it wasn't stable.
I suspected it is the underlying audio library, NAudio, so I changed the Wasapi 
driver to WaveOut -> I cannot replicate the issue now. Turning back to Wasapi 
replicated the issue immediately.
I'm going to contact the NAudio author and try to get some help on this.
In the mean time, I'm considering releasing 1.6.1 with WaveOut driver always 
selected.

Original comment by yuva...@gmail.com on 11 Feb 2013 at 1:26

GoogleCodeExporter commented 9 years ago
I do not know why NAudio acts the way it does.
Move back to Waveout driver for all OS - it seems stable.

It is a workaround, not a real fix, but I cannot fix NAudio. Will raise it to 
NAudio author.

Original comment by yuva...@gmail.com on 5 Mar 2013 at 1:55

GoogleCodeExporter commented 9 years ago
Related to defect #12

Original comment by yuva...@gmail.com on 21 Mar 2013 at 1:54