This project has moved. For the latest updates, please go here.

2.3 Beta 15 Monitor not queing media

Dec 30, 2013 at 3:00 PM
Upgraded from 2.3.14 to 2.3.15 (most recent build) and MCE Buddy no longer seems to queue any file in the monitored directory. I can manually add for the short term.

Cannot find any information in the logs, how do I diagnose why it is not selecting files?

I am currently working with VOBs that I am converting to MP4 and playing with different conversion settings to dial in the best size vs. quality trade off. With 2.3.14 I cleared history and the VOBs were queued right up. I've checked what I know how to and all looks just like it was other than the upgraded software.
Coordinator
Dec 30, 2013 at 3:27 PM
Wierd, I just tested it and it's working (on a clean install). Can you upload your mcebuddy.log file, it'll show what's going on.
Best way to trace, first see if it's finding the files, then see if it's queuing them for conversion.
Dec 30, 2013 at 4:11 PM
All it says in the log:

INFORMATION> --> No accessible files founds in the location E:\Test for monitor task windows Default

However on a hunch, I noticed that the list of extensions was lower case so I change the extension from .VOB to .vob and off it went.

The uppercase always worked as far as I recall, is this a known change that I missed?
Coordinator
Dec 30, 2013 at 5:14 PM
That is weird, I made some changes to the scanning function recently so that it doesn't stop scanning if 1 file is inaccessible but no changes to the pattern matching algorithm.

Can you try one thing, rename the file from .vob back to .VOB and see if it fails? (same file that works).


Dec 30, 2013 at 6:29 PM
Changing it back to .VOB and clearing the history, it does not work.
Coordinator
Dec 30, 2013 at 7:57 PM
Are you using yesterday's build? I'm not able to replicate it, no matter what extension I use/capitals etc it's working fine.
The pattern matching algorithm changes the case of the file name to lower and does a case-insensitive match - so it cannot be that (and I checked it''s working fine).

Is your antivirus locking the file? Is the some other software that working in the directory and locking the file? I've also found that sometimes just having the folder open in explorer on your desktop can cause the files to get locked.

Try this, rename the file back to .VOB, clear your history and then restart your machine. Now see if MCEBuddy is able to detect it
Dec 30, 2013 at 9:21 PM
Tried the above and more, very odd, problem seems to be with that particular directory, when specifying a different directory to monitor, it works. Not sure why one directory would be any different than another.

Yes, using last night's build.

Appreciate your help, very odd, probably best just to move on at this point and keep alert to similar in the future.
Jan 2, 2014 at 2:13 PM
Ran into this issue again when I unchecked 'Monitor subdirectories' which I was doing the first time, checking 'Monitor subdirectories' causes media to be found properly, unchecking and no media is found.
Coordinator
Jan 2, 2014 at 3:00 PM
check your folder permissions, if the mcebuddy doesn't have access to the folder it won't pick up files in it. When you check sub dirs, it again checks the permissions for each sub folder and if it has access to it, it'll process it. The 2 are mutually exclusive in 2.3.15 (earlier, if either one failed, it would stop processing)
Jan 2, 2014 at 3:12 PM
I did check the permissions and they are identical on both the parent and children and open access to all.

I am not explaining my observation adequately.

If I have a.wtv in the parent folder and then b.wtv in the child folder and I point MCEBuddy at the parent and uncheck 'Monitor Subdirectories' it says there are no files to process. If I check 'Monitor Subdirectories' then it will process both a.wtv and b.wtv. Same if I remove the subdirectory, it will find or not find a.wtv based on this setting.

This is what was happening when I first reported the issue, I just did not get the connection between this option and observed behavior and I will re-verify when I have time that this is a change in behavior between the current and previous version.

I am running 2.3.15 from 12/31.

Will continue to observe.
Coordinator
Jan 2, 2014 at 4:16 PM
I'm putting up a new build with a slight change in the way the directories and files are scanned (it's possible that enumeration is causing it to return an empty string under heavy load). This way will be slower when processing a very large amount of files.

Try it out and see if the fixes the issue.


Jan 5, 2014 at 1:28 PM
Running 2.3.15 64bit - 20120103, same observed behavior.

Have a single recorded program in a directory, no subdirectories, permissions on both set to allow all actions for everyone.

Checking 'Monitor Subdirectories', then clearing history, the single program is queued, unchecking 'Monitor Subdirectories', that program is never queued.
Coordinator
Jan 6, 2014 at 1:55 AM
I'm completely unable to replicate this issue, so am at a bit of a loss here. Is this happening with only that 1 directory or any directory?
If it's any directory, I'll create a special build for you with more debug messages to help get to the bottom of this. If it's just the one directory, post the log file with the latest build and I'll see if it's something about the directory name (just guessing) which might be throwing it off.
Jan 6, 2014 at 4:57 AM
I'm seeing the same error - moving the same file between two different subdirectories (or to the root folder) fixes it.
Coordinator
Jan 6, 2014 at 3:25 PM
I'm putting a special build for you guys called DEBUG in 2.3.15 directory. It has extra debug messages while it searches folders for files and subdirectories etc.

Try it out, with both situations and then post your mcebuddy.log file here. Lets see what's going on.


Jan 6, 2014 at 5:03 PM
Failed directory, beta and debug builds:


2.3.15 20140104 64 bit
2014-01-06T10:39:58 MCEBuddy.Engine.Core --> MCEBuddy engine started. Setting engine last running state to start.
INFORMATION> --> No accessible files founds in location E:\Video\Pre for monitor task E:\Video\Pre
INFORMATION> --> No accessible files founds in location E:\Video\Pre for monitor task E:\Video\Pre
INFORMATION> --> No accessible files founds in location E:\Video\Pre for monitor task E:\Video\Pre

2.3.15 DEBUG 64 bit

2014-01-06T11:00:45 MCEBuddy.Engine.Core --> MCEBuddy engine started. Setting engine last running state to start.
--> GETFILES: Searching in directory -> E:\Video\Pre with option TopDirectoryOnly
INFORMATION> --> No accessible files founds in location E:\Video\Pre for monitor task E:\Video\Pre
Jan 6, 2014 at 9:22 PM
Will try to free up a block of time to work on this, however, I was curious about 'E:\Video\Pre' and wondered if that was the full directory or there was a space after 'e' and a longer name.

In my case I've always used "E:\Recorded TV" so I tried a quick test and tried renaming it to "E:\RecordedTV" but since MCE has it locked I could not so I created a new directory E:\Test and now no matter what I do no media are found in this new directory.

I get the same messages "No accessible files found...", assuming I download and run the special build, do I need to turn on 'Debug' level messages to get the messages you need?
Coordinator
Jan 6, 2014 at 10:10 PM
Yes please set it to DEbug to get the details, otherwise it won't work.


Coordinator
Jan 6, 2014 at 10:10 PM
Meklos wrote:
Failed directory, beta and debug builds:


2.3.15 20140104 64 bit
2014-01-06T10:39:58 MCEBuddy.Engine.Core --> MCEBuddy engine started. Setting engine last running state to start.
INFORMATION> --> No accessible files founds in location E:\Video\Pre for monitor task E:\Video\Pre
INFORMATION> --> No accessible files founds in location E:\Video\Pre for monitor task E:\Video\Pre
INFORMATION> --> No accessible files founds in location E:\Video\Pre for monitor task E:\Video\Pre

2.3.15 DEBUG 64 bit

2014-01-06T11:00:45 MCEBuddy.Engine.Core --> MCEBuddy engine started. Setting engine last running state to start.
--> GETFILES: Searching in directory -> E:\Video\Pre with option TopDirectoryOnly
INFORMATION> --> No accessible files founds in location E:\Video\Pre for monitor task E:\Video\Pre
Can you post your mcebuddy.log file (zip and upload to mcebuddy server or dropbox).
Coordinator
Jan 6, 2014 at 10:12 PM
Also, before you upload, once set the option to no subdir and run, then set to sub dir and run. that way I can see exaactly what's doing on in teh same log file
Jan 6, 2014 at 10:15 PM
I made a new directory called Video, then created subdirectories under that called Pre, Precut, Postcut, Post, Encoded. E:\Video\Pre can't be accessed, E:\Video can, E:\Video\Post can, and I think the rest can as well...

I created them so that I could try different pieces of the process. If it were an all-in-one, I would drop it in Pre and it would be comskipped/cut and H.264 encoded, then dropped in Post. During my testing, I broke it out into different pieces of the job.... First just a comskip and cut, so from Precut to Postcut. Then an encode, so from Postcut to Encoded.

That lets me separate the different parts and see what is going on. I've even tried using multiple products (MCE Buddy, VAP/VideoRedo, DVRMSToolbox) to accomplish different parts of the whole... e.g. comskip/cut with MCEBuddy, encode with VAP/VideoRedo (which does not work BTW).

Some of the scenarios were fairly entertaining... like how if you told VAP to both comskip/cut and encode to H.264 with the default WTV profile, it would turn a 280MB original 30 min SD MPEG 2 video into a 450MB 24 min 5Mbit H.264 video.... but if you ran a separate job for the comskip/cut it generated a 223MB 24 min MPEG 2 video, then encoding to 9.5Mbit H.264 took that to 187MB.

I just want one product that will take an MPEG 2 source file from my HDHomerun Prime tuners, run a comskip/cut on it, and output a smaller H.264 encoded WTV file for display on XBox 360 extenders. I have a theater machine that does all the recording and playback via extenders, and I have other machines in the house too. I want to be able to have the option of either doing it all on an external box (like my desktop), or potentially splitting the task (comskip/cut on the theater machine, encode on my desktop and toss the file back across the network).

I would also love to have flexibility like "Do this set of tasks with files that match this string (or that are HD, or that are above this rating, or that were recorded from this channel, etc etc etc), and do this other set of completely different tasks with this other set of files from either the same directory or a completely separate directory. But for now, I'll be happy with baby steps.
Jan 6, 2014 at 10:23 PM
rboy1 wrote:
Also, before you upload, once set the option to no subdir and run, then set to sub dir and run. that way I can see exaactly what's doing on in teh same log file
If I set to Subdir, I will have to clean out the directory structure (otherwise that will try to comskip and encode everything I've been working with). That'll take me a few. I posted the 2.3.15 debug log from the failed nosubdir attempt.
Coordinator
Jan 6, 2014 at 11:44 PM
There are only 3 reason why it wont work:
  1. The .NET Framework is broke - NOT likely
  2. The file pattern match used to located files is not correct - this is a possibility, currently MCEBuddy uses . to find files. I've seen reports when users have said this doesn't work.
  3. For later
I've put a new build DEBUG1 with a new file search pattern (*) and without any subseqent reordering. Try this new DEBUG1 version and see if it fixes the issue.
Jan 7, 2014 at 7:22 AM
Setting to Subdir worked with the first DEBUG build. It processed both the file in the Pre directory and also a file I left in the failed_files directory for good measure (log uploaded). Now trying the DEBUG1 build.
Jan 7, 2014 at 7:43 AM
Same behavior with DEBUG1. Without subdir set, would not process files in Pre. With subdir set, it processed both the Pre directory and an underlying file in Pre\failed_files. Logs uploaded.
Jan 7, 2014 at 12:47 PM
Same behavior with DEBUG1, ran multiple permutations, log uploaded.
Coordinator
Jan 7, 2014 at 2:46 PM
Guys I'm at a loss here, there nothing I can find that shows why it isn't working.

On your computer the MOST BASIC windows API call to Directory.GetFiles is failing to return any files. The only conclusion I can draw is that either .NET installation is corrupted on your computers or that some 3rd party program like a antivirus is interfering with your files which is preventing windows from returning them.

lightman, can you go back to 2.3.14 and if the problem dissapears. That's the only thing we haven't tried.
Jan 7, 2014 at 3:07 PM
Went back to 2.3.14 and it works every time, with or without subdirectories checked, in both my Recorded TV and Test directories, flawless as far as properly selecting media to queue.

This is my original system that I used for MCE Buddy and then I retired when I moved to a production system but am now using to test 2.3.15. It is fairly barebones Windows 7 Pro 64, the only security software running is Microsoft SecurityEssentials as I don't use the system for Internet browsing but didn't want zero protection, I do have the E: drive excluded from scanning.

Something has changed between 2.3.14 and 2.3.15.

What else can I do to help narrow the issue?
Coordinator
Jan 7, 2014 at 3:42 PM
hmm now this is helpful. Let me look into this and get back to you.


Coordinator
Jan 8, 2014 at 8:53 AM
@lightman2, @meklos - I really appreciate you guys helping me out here. Apologize for the run around but i've found the issue and fixed it. It was staring at me the whole time in the FACE. The issue you're facing was happening ONLY where there was exactly 1 file in the directories AND/OR subdirectories.
Anyways, I'm putting up a new build and it should zoom zoom going forward with some extra performance boost for large file systems. should work better than 2.3.14 now. Enjoy
Marked as answer by rboy1 on 1/29/2014 at 8:47 AM