View Issue Details

IDProjectCategoryView StatusLast Update
0015670MediaMonkey 5Podcastspublic2019-05-31 22:56
Status closedResolutionreopened 
Product Version5.0 
Target Version5.0Fixed in Version 
Summary0015670: Freeze on startup
DescriptionI've been seeing this at least 3 times in the last couple of builds: when MM starts up and downloads podcasts, it will often freeze while it is in the process of 'loading...' and tagging multiple podcasts (see image below). On closing, the screen turns grey and a crashlog results: 370E0DF9

Note: I started the debug log just after I launched MM5 2175, so it might be missing a few lines at the beginning. Also, in this instance, I navigated to Artists and typed a contextual search for 'Kinks', but the bug has occurred even when I didn't do so in the past.
TagsNo tags attached.
Fixed in build2179


related to 0015673 closedLudek MediaMonkey 5 Occasional crash on startup (regression?) 
related to 0007780 closedLudek MediaMonkey (current) Images in podcast folders aren't assigned to Podcasts on download 
related to 0014918 closedmichal MediaMonkey 5 Slow scan of files with >1 covers 



2019-05-15 15:44


podcast_stalls.7z (35,648 bytes)
podcasts_stall.jpg (17,597 bytes)
podcasts_stall.jpg (17,597 bytes)


2019-05-16 15:01

developer   ~0053540

Last edited: 2019-05-16 16:15

View 6 revisions

In the debug log I see many many lines like:
Cover C:\Users\Russell\Music\Podcasts\Stuff You Should Know\Short Stuff- Honorary Degrees.mp3\AlbumArtSmall.jpg added for audio file C:\Users\Russell\Music\Podcasts\Stuff You Should Know\Two Times In the 70s When People Buried Ferraris(1).mp3

Cover files like
C:\Users\Russell\Music\Podcasts\Stuff You Should Know\How Trampolines Work.mp3\AlbumArtSmall.jpg
were assigned to hundreds of episodes (which took about 50 seconds on your machine) -- on the background.
It seems that the bug is that the artwork files are re-assigned to all episodes after each episode downloading (to be confirmed and fixed)

I just wonder how the artworks files got there? I guess that you had to add them manually to the podcasts folders?
I guess you added them manually in course of testing 0007780 ?

Nevertheless although all the cover files assigning to the podcast files is time consuming in the log -- it was not (probably) reason for the freeze.
I cannot find the exact reason for the freeze, because you did not start DbgView prior to MM5 start and thus many debug lines are missing.
Could you please generate one more debug log, but be sure that DbgView is started prior to MM5?

EDIT: Please generate the log from build 2176 (not 2175) -- I found that I had a bug in the debug code and there are callstacks of the tasks being queued (instead of the running tasks).
I need to add callstack info for the running tasks to find which tasks are blocking.


2019-05-16 16:08

developer   ~0053541

Last edited: 2019-05-16 19:16

View 2 revisions

Fixed various tweaks + added much better debug info re the running tasks into the build 2176

EDIT: And also there have been a bug in the artwork pick-up code for podcasts (0007780) -- in MM5 only
This caused the erroneous re-association for hundreds of episodes after each episode downloads, in addition it added a bad/deadlink path like
C:\Users\Russell\Music\Podcasts\Stuff You Should Know\How Trampolines Work.mp3\AlbumArtSmall.jpg
correct should be
C:\Users\Russell\Music\Podcasts\Stuff You Should Know\AlbumArtSmall.jpg

=> Fixed in 2176


2019-05-24 17:16

administrator   ~0053626

Last edited: 2019-05-24 17:20

View 2 revisions

Tested 2178.
1 Installed 2178 and ran it
--> podcasts started updating, but froze while 'Updating Podcast... Brainstuff'
2 After waiting about 10 minutes while it was stuck, attempted to close MM
--> nothing happened and I had to force-terminate MM

Note: upon restarting MM podcasts continued updating successfully. I've attached a second log of this successful update in case it provides some useful info for comparison.


2019-05-24 17:17


bug15670_build2178.7z (127,720 bytes)


2019-05-24 17:20


bug15670_build2178-log2.7z (77,084 bytes)


2019-05-24 20:36

developer   ~0053630

Last edited: 2019-05-24 20:52

View 4 revisions

In both logs I see:

1) "TIndyHTTP.GetResponseContent EXCEPTION!!! : Host field is empty ,URL: http://, ResponseContent.Size: 0"
You have five podcasts with url like http:// only.
But these are handled exceptions, so there shouldn't be any reason for a freeze or crash.
I only remember that Eureka had issues also with handled exceptions in the past and could cause a freeze (previously when there was a lot of 404 exceptions).
I will adjust also these (to ignore URL like 'http://' instead of attempting to read it and resulting in a handled exception)
=> Fixed in 2179

2) "AutoGenerateVideoThumbs: cannot access \\\Qdownload\Source Code (2011)\Source.Code.2011.720p.BrRip.x264.YIFY.mp4"
The share \\\ is inaccessible and in the first log it took 24 seconds to check the accessibility on background, in the second log it took 0.9 second, but in both cases it is not a reason for a freeze.

So probably Eureka with combination of the handled exceptions (item 1) somehow caused it.
The task queue was all right in both logs (3 threads of 10 running at max).


2019-05-31 22:56

administrator   ~0053695

Verified 2179.