[mikeb8591]

@mikeb8591

After a little more investigating, the reason your mcebuddy files are failing is because they are the old dvr-ms file format, not wtv (even though the files have the extension .wtv). Our remuxer can't handle dvr-ms, only wtv. Recheck how they are being created in mcebuddy and make sure that it is creating actual wtv files.

They believe they're creating .wtv files. I've examined the start of the file, and it certainly looks more like my wmc created .wtv files, than it does an old wmc created .dvr-ms file I had laying around. rboy1 at mcebuddy did mention they are using the most recent ffmpeg, and there could be problems if swmc is using an older version.

dvr-ms:

30 26 B2 75 8E 66 CF 11 A6 D9 00 AA 00 62 CE 6C 97 C6 00 00
00 00 00 00 06 00 00 00 01 02 40 A4 D0 D2 07 E3 D2 11 97 F0
00 A0 C9 5E A8 50 E8 2D 00 00 00 00 00 00 48 00 2C 00 44 00
56 00 52 00 20 00 49 00 6E 00 64 00 65 00 78 00 20 00 47 00
72 00 61 00 6E 00 75 00 6C 00 61 00 72 00 69 00 74 00 79 00

.wtv (converted):

B7 D8 00 20 37 49 DA 11 A6 4E 00 07 E9 5E AD 8D 8C C3 D2 C2
7E 9A DA 11 8B F7 00 07 E9 5E AD 8D 01 00 00 00 02 00 00 00
00 10 00 00 00 00 04 00 08 04 00 00 00 00 00 00 10 13 04 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 42 13 04 00 80 13 04 00 00 00 00 00

.wtv (wmc created):

B7 D8 00 20 37 49 DA 11 A6 4E 00 07 E9 5E AD 8D 8C C3 D2 C2
7E 9A DA 11 8B F7 00 07 E9 5E AD 8D 01 00 00 00 02 00 00 00
00 10 00 00 00 00 04 00 08 04 00 00 00 00 00 00 11 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 5C 5D 08 00 40 2B 0E 00 01 00 00 00

Would you be willing to speak directly to the developers at that project? Their email is mcebuddy2x _at_ gmail.com

[krustyreturns]

A wtv file has metadata in a file header for the first 0x40000 (hex) bytes of the file. Since you are using a hex editor, go to 0x40000 in a wtv file and go to the same place in the converted file. That's what I am doing in the image below. Your converted file is on top and a random wtv file is on bottom. In the lower file you can see where the metadata ends at 0x40000 and also that it is where the video data begins. The converted file on top (the one you sent me) is obviously very different, the video portion of the data has already started by 0x40000 (I have not bothered to find out where the video data actually starts in the dvr-ms).

http://imgur.com/MDNkTc1

I tried this for some other dvr-ms files I had on my computer and they all look like your converted file. Our wtv remuxer reads the metadata below 0x40000 and then starts reading video data at 0x40000, that's why it fails on your file.

[mikeb8591]

Hmmm. Curiouser and curiouser. The latest asf viewer I could find at microsoft doesn't have any problems with my .dvr-ms file, but won't open either of the .wtv files. If the file has wtv metadata but dvr-ms structure, I'd kind of expect everything to barf on it, yet it pays fine on kodi if it's not played through the swmc pvr client, and fine on wmc. (and in my experience, ms isn't very forgiving.)

Does swmc use ffmpeg? Given the lack of info about .wtv files, is it certain where the data is supposed to start within the file, or could the leading metadata be variable in length?

Are you interested in working with the mcebuddy guys to see if it's possible to work this out?

Thanks!

[krustyreturns]

Sorry my last post was misleading, what was causing our remuxer to crash was actually the metadata - it never even made it to the point where it would start reading video data - so the assumption that the metadata is correct wtv metadata for these files is not true. For example, the size of the wtv file (in multiples of 0x1000) is a long found at the file location 0x5C. This value is crazy wrong in the converted file you sent me. Also there is a metachunk table located at 0x11000 that is critical for correctly reading the rest of the wtv file and this table doesn't exist in the converted file. This website has some background info if you are interested:

http://wiki.multimedia.cx/index.php?title=WTV

We do not use ffmpeg to remux the file. If the mcebuddy guys have questions for me I'd be happy to answer them, but I am not really interested in changing the remux code to handle whatever strangeness is going on here, and I am confident we know how to read wtv format at least as windows drivers generate it.

Trying to solve this problem by using the remuxer to play these files is not the right direction to go in IMO. Instead I think you should be trying to understand why the converted files don't play normally in kodi on the oe box, since it works fine in windows.

[mikeb8591]

Trying to solve this problem by using the remuxer to play these files is not the right direction to go in IMO. Instead I think you should be trying to understand why the converted files don't play normally in kodi on the oe box, since it works fine in windows.

But they do play normally in kodi proper. Just not in the wmc.pvr plugin, which reads the meta data.

There's a lot of configuration in mcebuddy for conversions, so I was hoping a discussion between you might reveal settings or an alternate conversion method that would yield a usable file. (usable, in my definition being something that preserves the original quality of the recording, and allows wmc.pvr access to metadata.)

Thanks!

[krustyreturns]

With the remuxer turned off, pvr.wmc just points kodi to the wtv file and kodi plays the file directly - pvr.wmc is not reading any data from the file (meta or otherwise) - kodi is just playing the file. On my windows system, kodi with pvr.wmc, plays these converted wtv file fine, but on your oe box it doesn't. I think you said it just spins for a while and then gives up. So the oe version of kodi is behaving differently when it plays the file in 'pvr' mode. So I suggest turning the remuxer off in swmc, restarting kodi, and then getting the kodi log after it fails to play the file and seeing why its failing. I'm not good at reading kodi logs, but I'd be happy to look at it too.

[mikeb8591]

Yep, it's sits and spins for awhile, and then returns. Looking at the recording info, only the synopsis is meaningful. The channel info is missing, and the recorded time is the conversion time, not when it was actually recorded. Going out of recording info, kodi hung (and no new info was written to the log).

Log is here, but nothing much except 'error opening'.

http://pastebin.com/t9txfft3

This is via tv->recordings same file (from same share location) plays fine via video->files

Thanks for your help.

[krustyreturns]

Yeah, not much help there, except that you can see that swmc has just handed the file path to the file to kodi and its kodi that is opening it. Try it again, but this time enable debug logging in kodi before you playback the file.

Also, please explain again why you are doing this file conversion in the first place. What format were these files originally?

[mikeb8591]

Log is here, but nothing much except 'error opening'.

Ok, I think I see what's happening now. I have a odd network setup. There's a different physical subnet attached to the WMC box, where I keep tv tuners, and some NAS for some (older WMC, new and converted SD recordings) The NAS and the WMC box are both dual nic, and have one interface on each network.

The WMC box (including SWMC) addresses the NAS on the subnet. Kodi talks to the WMC box and NAS (directly) on the main network. Since SWMC is giving out this subnet address for the file, Kodi can't reach it. Remuxing worked (for original file) because the file would then come from SWMC not direct. (I didn't realize this part of the puzzle, I thought SWMC always streamed the files.)

To do what I want, it seems like I would have to allow the WMC box to address the NAS on the main net. I was trying to avoid that to keep recordings happening on a different network so as not have it interfere with with traffic on the main net, or vice versa. (Ethernet tuners, so each ongoing recording on the WMC box is tuner->box->NAS) Or I guess I could allow the WMC box to forward between the networks, and install a route on the oe kodi box.

This explains why the files play ok from accessing the share directly from Kodi, but not when the smb uri comes from SWMC

sigh.

[mikeb8591]

Also, please explain again why you are doing this file conversion in the first place. What format were these files originally?

The files are .mpg files produced by the Silicon Dust DVR. Unless I'm using their app though, there's no metadata (plot, when/where recorded) shown in the UI. Since I have WMC recorded info, it seemed like a good idea to convert the SD files to wtv and put them in the folder WMC would see for playbacks.

Thanks!

[krustyreturns]

Nice detective work. I'm just happy to be off the hook, at least for now.

[mikeb8591]

Yeah, about that. :-)

I was hoping updating to the latest openelec/kodi/pvr.wmc would fix this, but I'm still not seeing correct metadata on these files.

The only thing correct on pvr.wmc is the plot/synopsis of the recording. Recorded date/time is the time of the conversion (like it's using the file time, instead of the meta data time)

The date/time thing is particularly annoying, since it thows converted episodes out of sequence when sorting by date, so they can be watched in order. Other data would be a bonus (channel/duration).

Would you look at this, when you have a moment?

[krustyreturns]

Have you checked the metadata stored in the file itself to make sure mcebuddy has set all the correct values there (wtvFile->properties->details)? I think it is strange that the description is correct but the other data is not.

[mikeb8591]

Recorded TV -> "Recording time" is present, which looks like it should be the time display in Kodi, instead of the File -> "Date created"

Channel Number and Station call sign (Recorded TV) are currently blank, but those are supposed to be filled in, in the next release of mcebuddy. Media->length is also not filled in yet, but I'm hoping that will be in the next release as well.

Thanks!

[krustyreturns]

@mikeb8591

Fyi, you were right about those wtv files created by mcebuddy (ffmpeg). The file format is different then how the windows drivers create wtv, but still valid. I just pre-released a version of swmc (1220) that fixes this in the remuxer.

As for the metadata stuff.. The mcebuddy guys just aren't filling out enough parameters for the media center library to read the data properly - in other words it's not just swmc but also wmc that isn't getting the correct values for these fields. However in the swmc build 1220 I added an option to get the data directly from the file if the wmc library manager doesn't. This should solve your rec time and channel problem. But you have to turn UseMetaDataForRecordings to true in the config.xml file of swmc to turn this on.

When the mcebuddy guys get around to fixing the metadata duration and stuff in their next release, make sure they also include the meta tag WM/WMRVEndTime or you are still going to have problems with the start and end time of the recording.