Print

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

[rick.ca]

I just upgraded to and registered Media Center 13.0.61. I'm using XP SP3. Although the program and my library seemed to be okay, I was reluctant to uninstall MC 12 immediately. I soon found, however, AVI files were being played in MC 12, even though I had deselected all file associations and reset them in MC 13. So I uninstalled MC 12 and rebooted. Then I found AVI files could not be played at all. On further investigation, I found the problem seemed to be restricted to AVI's downloaded in the last several weeks and which had not yet been imported into MC 12 (I have no idea why that might make any difference). As far as I can tell, all older files that were previously imported to MC play fine. MC 13 does not seem to recognize the newer files as valid AVI's (they are—they all play fine in VLC) and it refuses to import them. Thinking this must be a codec problem, I reinstalled the latest version of CCCP. That made no difference. Unfortunately, I did not take note of the DirectShow playback settings I was using (without problems) in MC 12—so I'm not sure how they should be set now. For AVI, it's set to use Video Mixing Renderer 9 with no source or other filters.

I found that by copying the files into another directory and then importing that directory, the files would be imported. By examining them in the Recently Imported playlist, I could see that they were being recognized as data rather than video files (no duration, bit rate, etc.). They would not import before because they were already there, but not visible as video files. So I set Video view to display data files, deleted them, and then tried importing again. They reappeared instantly—all that did was reinstate the database entries. So I "Updated library from tags"—to see if maybe the latest DirectShow settings would make a difference. They seemed to take an unusually long time to scan (about a minute each), but were still not recognized as video files.

So what's happening, and how do I fix this?

[Yaobing]

You can try the following:

1. In DirectShow Playback Settings, make sure AVI is played in DirectShow, and select AVI Splitter from "Other Filters" list.

2. Find out what video codec is contained in the avi file, and select corresponding video decoder from "Other Filters" list.

3. If the files still are imported as Data, your last resort is to simply change the Media Type from Data to Video in Tag editor.

[rick.ca]

Thanks! Things are working again, but I'm not sure why, so I'll outline what I did...

1. Selected AVI Splitter.

2. GSpot reports codec of these, and other files that do work, as XviD—"codec(s) installed." I didn't see this in the list, so selected ffdshow Video Decoder.

3. The files were still imported as Data, so I changed Media Type and rescanned them (i.e., Update library form tags) to add the media information.

Unfortunately, I didn't try them before doing 1 & 2, but new AVI files work fine. So the problem was clearly restricted to files which had not been imported to the MC 12 library. My theory is my DirectShow settings immediately after installation of MC 13 were incorrect, and video files not previously imported were therefore imported as Data files. Subsequent attempts to play or import the files would fail because they were already in the library, incorrectly typed. If this is correct, I suppose the significant lesson (for me) is MC always uses the media type recorded in the library to determine how a file should be handled, even if the file is opened directly from the file system. And since deleting and reimporting the files just reinstates the erroneous information without rescanning the files, the only way to fix it is to edit the tags, then rescan.

[rick.ca]

It seems my problem is still unresolved.

Once again, when I import new videos, the scan is unusually slow and the files end up being imported as Data. This time, however, when I changed Media Type and rescanned them, they were changed back to Data. So I played each one, advancing each to the end before stopping (I don't know why, but I had to do this for this to work). Then when I rescanned them, they updated properly.

Possible cause: The first few files in this batch scanned correctly. The next file was one with an AVI extension, but was actually a null file (when done with a video, I create a null file with the same name and delete the original—as a means of logging my viewing of it). Then all files after that—valid AVI or not—were treated as Data. I wonder if the scanner, after encountering a null AVI, is somehow retaining the notion all AVI's are data.

It seems very likely my problem is the same as 426 videos not to be found, but I don't yet see anything there that might help.

[JimH]

Did you try cccp?

[rick.ca]

...Thinking this must be a codec problem, I reinstalled the latest version of CCCP. That made no difference.

I did so again yesterday—after noticing the problem had returned. BTW, when I first started using MC 12 and CCCP, I believe I did a fairly thorough job of cleaning all previously installed codecs from my system.

[JimH]

Did you install the Divx software?  It can cause problems.

[rick.ca]

No. That's the sort of thing I got rid of when I originally installed CCCP—I followed the advice in the DirectShow Playback Guide.

[rick.ca]

After conducting a "controlled experiment" and studying log files, I found the cause of this behaviour: Once the import of one AVI fails, the program no longer calls the correct analyser, so any subsequent attempt during the current session will fail. My experiment was to import the following files:

E:\Test\1 350 MB video.avi
E:\Test\2 Null file.avi
E:\Test\3 350 MB video.avi

The first and third files are normal AVI videos which have been previously imported (with different names) without incident. The second file is a null file which is expected to "break" the scanner so it will fail to properly import the third file.

As expected, the first file imported correctly. According to the log (and making a long story short), the program calls JRWorker.exe with the /AnalyzeDX parameter to do so.

For the second file, of course, this fails. It tries again with a /AnalyzeRP parameter (apparently something to do with a "RealPlayer engine"). This too fails, and the file is therefore added as a Data type.

Here is where the problem is: When the third file is processed, the program calls JRWorker.exe with /AnalyzeRP, instead of the /AnalyzeDX parameter.

The second part of the test was to change the name of E:\Test\1 350 MB video.avi to E:\Test\4 350 MB video.avi, delete the other two files, and import the folder again. The result was the same—the /AnalyzeRP parameter was used immediately, and the file was imported as Data.

Finally, I shut down MC, changed the name of E:\Test\4 350 MB video.avi to E:\Test\5 350 MB video.avi, restarted MC, and imported the folder again. This time, the file was properly analysed using the /AnalyzeDX parameter, and the file was correctly imported.

[JimH]

Thanks.  We'll check.

[rick.ca]

This issue still exists in version 13.0.78. Has anything changed? Should I repeat my experiment? Is there any other information that would help?

[imugli]

I just upgraded to and registered Media Center 13.0.61. I'm using XP SP3. Although the program and my library seemed to be okay, I was reluctant to uninstall MC 12 immediately. I soon found, however, AVI files were being played in MC 12, even though I had deselected all file associations and reset them in MC 13. So I uninstalled MC 12 and rebooted. Then I found AVI files could not be played at all. On further investigation, I found the problem seemed to be restricted to AVI's downloaded in the last several weeks and which had not yet been imported into MC 12 (I have no idea why that might make any difference). As far as I can tell, all older files that were previously imported to MC play fine. MC 13 does not seem to recognize the newer files as valid AVI's (they are—they all play fine in VLC) and it refuses to import them. Thinking this must be a codec problem, I reinstalled the latest version of CCCP. That made no difference. Unfortunately, I did not take note of the DirectShow playback settings I was using (without problems) in MC 12—so I'm not sure how they should be set now. For AVI, it's set to use Video Mixing Renderer 9 with no source or other filters.

I found that by copying the files into another directory and then importing that directory, the files would be imported. By examining them in the Recently Imported playlist, I could see that they were being recognized as data rather than video files (no duration, bit rate, etc.). They would not import before because they were already there, but not visible as video files. So I set Video view to display data files, deleted them, and then tried importing again. They reappeared instantly—all that did was reinstate the database entries. So I "Updated library from tags"—to see if maybe the latest DirectShow settings would make a difference. They seemed to take an unusually long time to scan (about a minute each), but were still not recognized as video files.

So what's happening, and how do I fix this?

Instead of changing the video settings to play data files, change the "File Type" field in the tag settings from data to Video.

[rick.ca]

Instead of changing the video settings to play data files, change the "File Type" field in the tag settings from data to Video.

Yes, Yaobing mentioned this, and I incorporated this in my subsequent testing. The issue is a bug in the video file scanning routine that, in my particular circumstances, renders the scanning function useless.

[imugli]

Yes, Yaobing mentioned this, and I incorporated this in my subsequent testing. The issue is a bug in the video file scanning routine that, in my particular circumstances, renders the scanning function useless.

That'll teach me not to read the whole thread 

[rick.ca]

...Here is where the problem is: When the third file is processed, the program calls JRWorker.exe with /AnalyzeRP, instead of the /AnalyzeDX parameter...

This issue still exists in version 13.0.82. Is this going to be fixed?

[Yaobing]

This issue still exists in version 13.0.82. Is this going to be fixed?

This happens because we are using a testing scheme to decide whether to use DirectShow for a particular file type. When a file of that type fails in DirectShow, we mark it as not playable in DirectShow and try playing/analyzing them using other engines - until MC is restarted. I know this is definitely not a perfect solution, but we have not found a better way of dealing with this.

[rick.ca]

Thanks for the explanation. I've changed my practise of converting AVI's to null files after they've been viewed. I might even use Auto-Import again, but...

It would be helpful if the scan failure event triggered an information message identifying the problem file and the consequences. Whether the testing scheme "works" or not, it seems likely to conceal problems that require user intervention.

[Daydream]

I believe issues related to this problem has been reported often enough so far, the current thread plus here, here, and probably a couple of other threads that fell off the first page and I lost track of them. How about we call the entire video importing routine in MC13 broken and have it fixed, instead of creating accolades of temporary solutions on the user side that waste more time than we bargained for?

[JimH]

I believe issues related to this problem has been reported often enough so far, the current thread plus here, here, and probably a couple of other threads that fell off the first page and I lost track of them. How about we call the entire video importing routine in MC13 broken and have it fixed, instead of creating accolades of temporary solutions on the user side that waste more time than we bargained for?

The problem is not the program.  The problem is that an AVI file is a container.  It may or may not contain video.  If you've told MC to use DirectShow, and there are no DirectShow filters present for the contents, MC will sort it into the data pile.

[rick.ca]

If you've told MC to use DirectShow, and there are no DirectShow filters present for the contents, MC will sort it into the data pile.

That's fine. But when the program then (for the rest of the session) processes all valid AVI's as data, it's a problem. This may be necessary to prevent the continued processing of a file type for which the necessary filters are broken. But the program should at least alert the user that a problem exists.

[Daydream]

Passing everything to jrworker.exe over what the end-used has almost no control. Only to have it run automatically or not to have it run, and even that if you look at people experiences it's such not a transparent option. MC stands tall above other collection/media center software (my opinion at least) because of it's unusual level of flexibility and options offered, beyond the ones that will be enough for Johnny Average. But where's the ability to re-launch jrworker on individual files or to stop it at once?

[venting removed by JimH]

[rjm]

Just ran into this problem for the first time.

GSpot confirmed that one of my avi's had the problem "file truncated in the legacy area". This caused DirectShow to fail and then every avi after that would not import properly.

Solution was to exit and restart MC. AVI's then imported as expected.

[edit]

Forgot to mention that BSPlayer uses DirectShow and plays the bad avi ok. Which leads me to wonder if MC can use DirectShow in a more fault tolerant manner?

[rjm]

In case anyone wants to fix one of these problematic avi's, Video Fixer worked well for me.

[rick.ca]

Which leads me to wonder if MC can use DirectShow in a more fault tolerant manner?

This happens because we are using a testing scheme to decide whether to use DirectShow for a particular file type. When a file of that type fails in DirectShow, we mark it as not playable in DirectShow and try playing/analyzing them using other engines - until MC is restarted. I know this is definitely not a perfect solution, but we have not found a better way of dealing with this.

I don't understand why a file type is marked as unplayable at this point. If another engine succeeds, use it for the rest of the session for that file type. But if they all fail, the sensible conclusion is there is a problem with one file. Log it and continue. If DirectShow fails and another engine succeeds for three files in succession, mark DirectShow unplayable. If all engines fail three times in succession, skip all the files of that type and log the results.

[Raphael Stark]

Hello, I have the same problem with .dts files. The new are recognized as a data, the other which I imported befor to my library are good recognized. What schould I do?

thanks
RaFi B
 

[Yaobing]

Hello, I have the same problem with .dts files. The new are recognized as a data, the other which I imported befor to my library are good recognized. What schould I do?

thanks
RaFi B
 

We introduced a new "Playback Method" configuration in MC13.  For dts files you should configure it to use DirectShow.

Go to Tools -> Options, and select "File Types" from the right pane.  In the left pane select "dts Audio (dts)" under Audio, and then choose "JRiver audio engine (using DirectShow)" from the drop-down list "Playback Method".

You may also try configuring DirectShow settings as in MC12.

For those files that were imported as Data, you can select them in MC, under Documents, and change their "Media Type" tag from "Data" to "Audio".