|
Ludek
2019-05-16 15:01
developer
~0053540
Last edited: 2019-05-16 16:15
|
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.
|
|
|
Ludek
2019-05-16 16:08
developer
~0053541
Last edited: 2019-05-16 19:16
|
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
|
|
|
rusty
2019-05-24 17:16
administrator
~0053626
Last edited: 2019-05-24 17:20
|
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.
|
|
|
Ludek
2019-05-24 20:36
developer
~0053630
Last edited: 2019-05-24 20:52
|
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 \\192.168.0.147\Qdownload\Source Code (2011)\Source.Code.2011.720p.BrRip.x264.YIFY.mp4"
The share \\192.168.0.147\ 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).
|
|
|
|
Verified 2179. |
|
