This has happened a few times just this evening. I'm not sure I quite understand what's happening but the lister is terminating unexpectedly. It seems to have to do with adding metadata columns onto the lister.
My first experience was I added the Artists column and was sorting back and forth and suddenly it stopped displaying the Artists data. it just became a empty column. Then I think I went into my browser and returned to DO and it closed on me reopening to my default lister. I went through this same scenario a few times but it's not consistant or at least I haven't figured out what the consitancy is other than it seems to happen when I reopen or bring it to the foreground?
The second time I had added Artists column yet again and was going through working on fixing filename structure and again I went to lookup something through the browser and came back to the lister and boom. It closed down and re-opened my default lister. I wasn't doing anything with the column other than identifying what files needed their metadata fixed. Again this happened multiple times.
Here's the list of files types that compose the lister data:
Disclaimer: I'm not saying that all these types have Artists column data. I'm working through these to clean up files that don't belong here or are missing their metadata or don't have the preferred filename structure and my cat just plopped onto my laptop so I cannot see what I am typing.
These are built-in and just the Artists column. I was just using that to see what files didn't have metadata.
I didn't see any evidence of any dump being created. There was no dialog box that popped up the program just closed and re-opened.
It just failed again. I have the Artists column showing but wasn't actively doing anything with it except scrolling right and left (overtop of it) to go from file name to file size. I was checking to make sure that duplicate files had at least one that played and occassionally deleting and/or renaming one of them. I just double clicked to open the next song in PotPlayer and boom. Down it goes and reopens with my default lister. It was a dual lister for what it's worth.
It may be a specific file that's triggering a crash, but it's a bit weird that the program just disappears and restarts - that suggests Windows is trapping the crash rather than let it fall through to our own handler.
You could try to work out which file triggers it - if you send it to us we should be able to fix the problem.
You could also have a look in the Windows Event Log and see if anything's mentioned for Opus in there.
I'm not aware of any specific file causing this. You're talking about a file that I might be accessing over and over via the lister correct?
Last night I had added the attribute column to another lister that was looking at media manipulation program installations. Some weird thing seemingly has changed several of my media program files and attributed them as system files when I try to reset the attributes it just simply changes them back to system again. Some don't even seem to respond to an attrib command and it's not just one application but multiple but it doesn't affect all installs within the Mediatool subfolder. When I look at the same installs on my desktop none of them have had their installed file attributes changed.
Anyway when I was trying to figure this out the same thing happened again. Boom and restart back to the default directory. I went through DSIM and SFC and it said it replaired some files. I'll see if it makes a difference.
Again it was a dual lister.
There are some DO events in the application log do you want them or want to wait and see if the system repair resolved the problem?
One of the files in the directory will probably trigger the crash when the column is populated for that file.
Easy way to track it down is to create a copy of the directory, then split the files in half and see if it still happens. If it still happens within one half, split that in half again, and so on, until you're down to just a single file that can trigger the problem on its own. Send us that file and we can look at it.
(It's also possible the crash won't happen for us, if it involves a 3rd party codec/demuxer rather than our own code, where we might have a different component installed for that file type. If so, we may still be able to suggest where to look for the component that needs updating/replacing, once we can look at an example file.)
If they match the dates/times the problem happened, the details are worth sending to us.
