Folder format "Music" crashes Dopus

i tried to synchronize the 2 folders. Several attempts were necessary because the Sync Tool would crash with the same error code at any time, i.e. during the folder loading process or during the comparison process ("Compare"-button):

At one point i was lucky and despite the crash window the Sync Tool ("Compare" module) would continue the comparing to the finish; time elapsed so far: 24min30sec :open_mouth:

[quote="leo"]The dopus_fileinfo thread is crashing there, which you can probably solve via this FAQ:

It's likely due to a shell extension or video codec, but if you narrow it down to whichever file(s) are triggering the crash it should be clearer where the problem lies (and whether it's in Opus itself or some other component on your system that is hooked into Opus, like a shell extension / codec).[/quote]
Thanks leo. The source folder in E:\ ("MP3-collection" with lossy formats: mp3, wma, m4a, aac, mp4, mpc, ogg incl. corrupt audio tracks which only error-tolerant players like 1by1 can play!) has the permanent folder format "Music" with the columns:
When i turn off the folder format (Preferences:Folders:Folder Formats:Path Formats:...), then the Sync tool would not crash. Apparently the cause of the crash isnt the Sync Tool but some problem between Dopus10 folder format "Music" and some of my file(s).

I think it is almost hopeless to isolate the audio tracks which make Dopus crash (the MP3 collection contains 100,000+ files!). Cant Dopus (folder format Music) simply be coded robuster in the first place? :smiley:

At least i know now: When i play with my MP3-collection (folder format ON) and Dopus crashes, then i simply turn off folder format and Dopus wont crash anymore :unamused:

It may not be Opus itself that's crashing. We can't tell until you give us a file that reproduces the crash.

Even if it is Opus, we can't magically make the code more robust without knowing where the actual problem is.

When tracking down this sort of thing, the best thing to do is divide the files up until smaller and smaller batches until you isolate one/some that trigger the problem. The easiest way to do that depends on how the files are organised.

I'd start with corrupt files, though.

You should be able to use Process Monitor to easily see what the last file is that Opus accesses before it crashes.

lol.. i would have guessed that the ("impossible") tracking down task is left to me the user. Sounds like lots of nonfun time and mucho sweat. I have turned off the global folder format "Music".. but i'll keep an eye on it and other Dopus users should be aware that

Folder Format "Music" and audio tracks can lead to "some crashing" (see the 2 screenshots in post#1). And this also affects the synchronization of folders (source vs. dest) if at least one of them contains audio tracks and has the folder format "Music" set ON. (then it would look like a crashing of the Sync Tool.. which it isnt.)

I will spend a little more time on investigating (tracking down the few audio tracks which could be called "responsible" for the triggering of the crash)..

I know "process explorer" (technet), but i will check out "process monitor" (technet), thanks for the tip!

You seem to have spent several days timing various copy functions for no real reason at all, im sure the 5 minutes it will take to download and run procmon won't be that onerous.

If you want to ship your computer to me I'd be happy to do it for you.

okay, am working on the tracking down!
stay tuna :slight_smile:

[quote="leo"]When tracking down this sort of thing, the best thing to do is divide the files up until smaller and smaller batches until you isolate one/some that trigger the problem. The easiest way to do that depends on how the files are organised.

I'd start with corrupt files, though.[/quote]
A good strategy when trying to home in on a dodgy file is to move half of them to a different location.

If the thing crashes again, move out another half.

When, at some stage, it doesn't crash, replace the half in there with the half that you just removed.

Repeat the process until you find the culprit.

This is a quicker way of finding a dud file than trying either batches from the original selection or single files.

thanks for the tip. news, thanks to procmon.exe:

Of the ten thousands of artists i was able to narrow down the artist whose folder (1.55GB artist folder = his/her discography) contains problematic albums. I even seem to have narrowed down the album or album range (128-288MB) where the crash first occurs when the folder format "Music" is turned ON.

I am very relieved to learn that the Sync Tool is innocent here.

The problem is, sometimes i can reproduce the crashing (e.g. by pressing F5, in Grouped Flat View Mode), and sometimes i cannot (e.g. by pressing F5). I've rebooted the machine (to clear RAM cache,..) x-times and "when i am lucky" the crashing would occur within the 288MB when i load the artist folder as a whole. Because of the difficulty to reproduce the crashing by a fixed step-by-step procedure, to me it is still unclear where/why/when the crashing occurs.

I've copied the 288MB (=3 albums) to another partition, set folder format to "Music" and rebooted the machine. When i load the folder with the 3 albums, no crashing occurs. So it is difficult to tell that "the 288MB's" are the very cause (and if i shared the 288MB's with you, maybe no crashing would occur at your part lol!).

The 288MB's might be problematic, but i cant tell for sure. i cant reproduce the crashing at all/any times, sorry!

If it´s only a few files, you could consider to reencode them, using something like X-Recode.
When you set it to maximum bitrate, you shouldn´t lose any quality.

http://xrecode.com/

newsupdate1:

With a 30% probability i am able to reproduce the crashing (always with the same error code see post#1) with a 3.26GB folder \Oliverbox\ (361 MP3-files of the same kind, 0 subfolders) on a different partition. The procedure which, in 3 out of 10 attempts, would help to lead to the crash are:

  1. Preferences:Launching Dopus:Startup:(SELECTED)Open the Listers that were open when the program was last closed
  2. the Lister for \Oliverbox\ be in globally saved Folder Format "Music" (Path Formats) with Group By Extension+Ascending. We see the 361 MP3 files in Details mode.
  3. close the lister, exit Dopus, and with Process Explorer make sure that "dopusrt.exe" is killed too.
  4. double-click on Dopus icon on Desktop. Dopus launches and the Listers tries to display all the details of the 361 files.
  5. only seconds after having clicked on the Dopus icon, Dopus crashes with "0x1523D98D" address error.

If it doesnt crash, then kill (Shift+Del) Dopus in Process Explorer, and go back to 2).
If it doesnt crash, then kill (Shift+Del) Dopus in Process Explorer, and go back to 2).
If it doesnt crash, then kill (Shift+Del) Dopus in Process Explorer, and go back to 2).
etc. etc. and at some time, maybe at the 8th attempt, Dopus indeed crashes, see 4).

With Process Monitor, i was able to capture 3)+4) within a minimal time frame of 2.6264941sec, and save it to "Logfile.PML.rar" (2.88MB). If this log file is of help, i'll email it to dev. My general observation so far is: While it is possible to reproduce the crash with a large set of mp3's, once you single out the problematic(?) files and try the crash procedure just on them (steps1-3), you hardly get to step4, i.e. Dopus doesnt want to crash!

No further testing from my part. If dev wants PML file or MP3's (which ones?) from the Oliverbox folder, please let me know and i will provide. But as i said, the crashing is reproducible only when you do steps1-3 on the entire Oliverbox folder and not on a reduced version of it.

@abr
the files (3.26GB of Oliverbox) are foobar2000 errorfree conversions from lossless FLAC to mp3 (lame -v0, v3.98.4) and i dont doubt the integrity of my files. a better question is what's up with the reoccuring 0x1523D98D? :smiling_imp:

Without a way to reproduce this on our end we don't have a lot to go on.

On an XP machine, 0x1523D98D is within WMVCore.dll, a component of Windows Media Player which Opus uses to get metadata from WMV, WMA and possibly (not sure) MP3 files.

Is your Windows Media Player up to date?

i've submitted a support ticket (not as support request but simply as a report) and included the Process Monitor logfile. As my own personal happy solution, I have simply disabled Path Formats for the problematic folders, and i am happy. So no further support or testing required for my part, thanks! :=)

(i have a fresh installation of WMP11 and no matter which WMP version i have (9, 10, 11 or 12), in my humble opinion Dopus should not crash by any means because it drives potential customers away from giving it a second chance. As i've heard from colleagues on other forums.)

All we know is that on your machine with whatever setup you have (which presumably includes a hell of a lot or random video codec installs & uninstalls from all that codec testing you did the other day), with a few hundred meg of MP3s that only you have access to, something crashes when Opus is extracting audio metadata.

Yes, it shouldn't crash, whatever it is, but we can't do anything about it with so little information.

Okay, I'll just sprinkle some magic 'don't crash' dust on all the code, including the code that makes up 3rd party components like video codecs and WMP.