Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bobbybea]

Curiously, since my updating to version 13, MC13 crashes everytime I try and auto-import on the following step (Updating library to match external...) To be exact, it also crashes on manipulation of the library files-- in "clean File Properties". In order to illiminate my server as the culprit, I have the exact same problem with two additonal computers on the network. Thus, the music network totals over 267,000 music files in an array located within the network, of which worked fine with MC12. All three machines seem to have the same issues related to the previously noted step following the "Importing Media", "fixing broken links, "Updating library to match..." So, anticipating the administrator's questions within this forum, I have created a new library, imported anew all 267,000 music files, and it too crashed once it gets passed the "fixing broken links". Truly, I would appreciate any ideas on this issue in order to avoid re-installation of MC12 on all network computers.

[JimH]

Welcome to the forum.  Sorry for the trouble.

It may be a bad DirectShow filter. 

Try importing single directories or single filetypes to help find the problem.

Which build of MC13 are you using?

[bobbybea]

I update and verify my version daily from the forum hoping a solution is available. Thus, .123 for now.

Your suggestion to import a single folder comes up perfect everytime. Further, I only import mp3 since I have no use for anything else. Subsequently, the problem never arises during single import because auto-import takes it a step further, that is, it cleans after import. The crash takes place on anything to do with the cleaning process of broken links (as indicated in my post). Background import seems to be running well enough but for the last two days, with background import on, MC13 crashes for no reason during playback or not during playback (It is on and not playing and because of background import, it crashes). In passing, the latter was not tested on all three machines--just the main server.

[JimH]

Try the "Stability" link in my signature.

Test on a local drive to eliminate the network as a cause.  (Import on the server.)

[bobbybea]

I appreciate the stability link and, fortunately, all notable trials have been tested several weeks back. I further add that the avoidance of the LAN has been offered in my posting under the use of additional machines. Hence, one such machine houses the actual array and still crashes on import--in fact, they all do (the shear number of files it undertakes cannot be of normal use for your typical user--hundreds of thousands of files.) Thus, when importing on the server, that is, an array does also exist on the server itself, which is the only WAN entry to be scanned by the Kaspersky corporate solution antivirus. In other words, no antivirus is available and wanted within the LAN itself. A brief daily scan takes place in the later hours because of obvious needs for active threats. I rely on gmer and Avira for rootkits (Linux based not locking up any Microsoft weaknesses) and I rely on Malewarebytes for other areas of the LAN for idiocies, and rely on KAV for incomming port monitoring (the only Windows-based intrusion detectors used within the LAN or WAN.) Additionally, No KAV, registry locks or any kind, or any other novice threat tools are relied upon within the LAN itself as there is no need for additional protection. Thus, plainly, MC13 does all the work it needs to import, relocate, and place all files in the appropriate context or format.

I am presently in the midst of an addtional trial on the server. Under the Auto-import options (search section under Tools), I have disabled the "Update for external changes" section seeing this is the culprit I speak of. Thus far, an import is taking place and MC13 has not crashed once in one hour of import and play. This is quite premature as of yet, however, when removing "Update for external changes" the system seems stable until further notice. I will post my findings once a result takes place.

What pertains to "Update for external changes" and how does that affect my library when disabled?

[JimH]

... the shear number of files it undertakes cannot be of normal use for your typical user--hundreds of thousands of files.

We have more than a few users with several hundred thousand files.

Thus, when importing on the server, that is, an array does also exist on the server itself, which is the only WAN entry to be scanned by the Kaspersky corporate solution antivirus.

Kapersky needs to be eliminated as a source of the problem.  Disable at a minimum.  Uninstall is preferred.

What pertains to "Update for external changes" and how does that affect my library when disabled?

If you've removed a file manually in Explorer, MC will update the library.  If you had another process running that was changing the files during import, it's possible this could set up a failure.  Explore the logs to see more.

[JimH]

Also check the "Weird Problems" link in my signature for other ideas.

[bobbybea]

Weird problems are not addressing Vista 64 OS.


The usual Event ID:1000, thus indicating the mp3.dll having issues with something.
Faulting application Media Center 13.exe, version 13.0.132.0, time stamp 0x49ac6229, faulting module in_mp3.dll, version 0.0.0.0, time stamp 0x49ac5dc6, exception code 0xc0000005, fault offset 0x0001802b, process id 0x1364, application start time 0x01c99d9c66a82df6.

Either way, Kaspersky does not monitor any internal activity connected with MC or its storage tiers (exclusion lists for both files and program.) I use several NATS, VLANs and groups (when needed) and never monitored by KAV that of which does not exit the system. With that said, I am mapping it additionally just in case something was missed.

In passing, MC13 has not crashed once on any machine since removing "Update for external changes". Further, it continues to remove broken links as we update the system in between imports but somehow seems to be missing a great number of changes (not during imports--although, this has never been a problem before.) I take it, it is no longer cleaning the system leaving behind these relics. Enable it and it crashes once again.

Successful imports take place without “Update for external changes” enabled. Knowing the MP3.dll is faulting I am presently analyzing audio files.

[Matt]

It sounds like there's an MP3 file causing a crash in in_mp3.dll when reading tags.

Please enable logging in Help > Logging.

Then, after a crash, email the log (using the email button on the logging dialog) to logs at jriver dot com.

My guess is we'll need to see the file that causes the crash, after which it will be a hopefully easy fix.

Thanks,
-Matt