Print

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

[muzicman0]

Why is this happening?  Sometimes it will be the same show for weeks, then all of a sudden it is fine.  Media type is being set to Audio instead of Video on recorded TV.  It has happened about 8 times in the last 2 months.  Not a ton, but certainly annoying!

[RoderickGI]

I suspect the only way to answer that would be to catch it in a log.

[ErikN]

I've had this occur and can explain the cause in my situation in case it helps. For me it occurs when there is corruption very early in the recording (i.e. weak or bad signal resulted in corrupted m2ts transport). The channel might be generally ok but JRiver seems very sensitive to errors early in the transport.

The over-the-air m2ts transport is extremely robust. Without getting too detailed, each element (audio, video, metadata, etc.) is given an ID and sent in small packets carrying the ID. There are mapping tables for the IDs which are repeated periodically. In case of corruption, there are sync words, continuity markers, and repeated opportunities to get the correct information.

It seems like MC looks only at the first (or at least only the very early) instances of ID tables and stream config when classifying a recording. When this has happened to me (going all the way back to MC21),
  - Forcing the media type of the recording usually fixes playback
  - ffmpeg transcodes audio/video to mp4 perfectly but warns of some corruption early on

[muzicman0]

Thanks.  that makes sense.  Early on, I discovered that when I transcode a video using FFMPEG, or whatever, I have to start a few seconds in, otherwise the AV sync will be off.  Sounds like it could be the same issue.

[RoderickGI]

It seems like MC looks only at the first (or at least only the very early) instances of ID tables and stream config when classifying a recording.

MC actually sets nearly all tags for a recording at the start of the recording. So if there is a problem early on, that would be reflected in the tags, regardless of whether MC reads the correct information later.

Not that that information changes the outcome. But it may help with the understanding.

[muzicman0]

You would think though, that MC should be smart enough to know that recorded TV is video.

[RoderickGI]

You would. But I guess MC could record an audio stream if that is what a channel played?

Australia used to have some "TV Channels" that just played audio and displayed a static image. I don't think there was any video involved, but maybe the static image was video under the covers?

[Yaobing]

You would think though, that MC should be smart enough to know that recorded TV is video.

Yes, as soon as the recording is started, we import the recording and set its media type to Video.

Do you have MC watching the TV recording folder for import?  It is not necessary to do it.  It is conceivable that if you let MC import it again when the file is created, the process may override the media type setting for some reason.

[muzicman0]

It doesn't seem to.  I am recording off site in .ts format, and transferring the files via OneDrive to my home server.  It is marked as audio on both PC's (the recording server, and the home server that imports it overnight).

[Yaobing]

It doesn't seem to.  I am recording off site in .ts format, and transferring the files via OneDrive to my home server.  It is marked as audio on both PC's (the recording server, and the home server that imports it overnight).

When a .ts file is imported, it may be imported as audio if whatever tool we use to analyze it does not find video packets from the beginning of the file.  When the recorded just starts on the recording machine, we know it is TV recording, so we set media type to video and media subtype to "TV Show".  When it is imported as a file (.ts), there is no way to tell it is a TV recording anymore.