[Bri1270]

So I was watching Batman Begins, The Departed and Field of Dreams. All movies play fine if I start from the beginning, but if I stop and try to resume, the audio will play, but there's no video. Also, if I fast forward Field of Dreams, the audio drops unless I go in and change the audio setting to not allow pass through mode. I don't have this problem with The Dark Knight or The Dark Knight Rises or many of my other movies. The one thing these three films have in common is that they were ripped from my HDDVD collection, I'm not sure if that matters.

Here's the debug log http://xbmclogs.com/pvcqavdis

I think the 'fun' begins at around line 800

[k4sh1n]

When you ripped the files where they muxed into a single transport stream or separate for additional audio?

Seems KODI has trouble resolving where about's the stream audio is derived.

The file header nominally contains the exif data at the start of the transport stream when it was encoded, and must give sufficient audio codec info to KODI to start from anywhere but the start of the header/file, so playing file from the middle or resume point gives issues (shouldn't not be the case as exif is always pulled or polled/refreshed with FFmpeg, unless the header has some weird issue). If you play in lets say VLC does the data represent true of the file, duration, codec, resolution, blah, blah, etc, etc?

Two paths of resolution are to:

Solution 1: Re-rip with a single muxed audio file, (unsure if you want to still use the same .m2ts container or go for a more friendly .mkv solution if including additional audio)
or
Solution 2: Try and perform an EDID override using monifo to use the marantz-AVR .inf information (thus keeping pass-through/bit-streaming). (YMMV) Link: Moninfo

Option 2 is the quicker and easier to try and test if it works, then go option 1.

Just addittional thoughts:

Is the audio device set as exclusive in windows and KODI to keep audio alive in KODI (may or may not help)
KODI>system>audio output>keep audio device alive>(change to always)

[Bri1270]

When you ripped the files where they muxed into a single transport stream or separate for additional audio?

Seems KODI has trouble resolving where about's the stream audio is derived.

The file header nominally contains the exif data at the start of the transport stream when it was encoded, and must give sufficient audio codec info to KODI to start from anywhere but the start of the header/file, so playing file from the middle or resume point gives issues (shouldn't not be the case as exif is always pulled or polled/refreshed with FFmpeg, unless the header has some weird issue). If you play in lets say VLC does the data represent true of the file, duration, codec, resolution, blah, blah, etc, etc?

Two paths of resolution are to:

Solution 1: Re-rip with a single muxed audio file, (unsure if you want to still use the same .m2ts container or go for a more friendly .mkv solution if including additional audio)
or
Solution 2: Try and perform an EDID override using monifo to use the marantz-AVR .inf information (thus keeping pass-through/bit-streaming). (YMMV) Link: Moninfo

Option 2 is the quicker and easier to try and test if it works, then go option 1.

Just addittional thoughts:

Is the audio device set as exclusive in windows and KODI to keep audio alive in KODI (may or may not help)
KODI>system>audio output>keep audio device alive>(change to always)

Hi k4sh1n, thanks for the reply.

I actually ripped using MakeMKV so it's all in one already. Only one audio track was ripped (DD+). And as I said, as long as I don't stop then try to restart, it plays fine...all of them do.

I will give this a look though, as I'm not sure what my current setting is:

KODI>system>audio output>keep audio device alive>(change to always)


And just for the heck of it, here's the media info on Field of Dreams rip:


Format : Matroska
Format version : Version 2
File size : 14.6 GiB
Duration : 1h 45mn
Overall bit rate : 19.7 Mbps
Movie name : Field of Dreams Feature
Encoded date : UTC 2015-03-23 18:04:35
Writing application : MakeMKV v1.9.1 win(x64-release)
Writing library : libmakemkv v1.9.1 (1.3.0/1.4.1) win(x64-release)

Video
ID : 1
Format : VC-1
Format profile : Advanced@L3
Codec ID : V_MS/VFW/FOURCC / WVC1
Codec ID/Hint : Microsoft
Bit rate : 17.8 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Original frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Scan order : Top Field First
Compression mode : Lossy
Language : English
Default : No
Forced : No

Audio
ID : 2
Format : E-AC-3
Format/Info : Audio Coding 3
Format settings, Endianness : Big
Codec ID : A_EAC3
Duration : 1h 45mn
Bit rate mode : Constant
Bit rate : 1 536 Kbps
Channel count : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 1.13 GiB (8%)
Title : Surround 5.1
Language : English
Default : Yes
Forced : No

[k4sh1n]

My thinking may not be 100%, per codec ID: Codec ID : V_MS/VFW/FOURCC / WVC1, and the running OS: Windows 8.1 x64 bit system.

I conclude:

The .m2ts container format used for multiplexing the audio/video of your movie with MakeMKV does not contain the proper interlaced exif data and probably just needs an alternate container. (probably)

Video Compression Manager (VCM) is a version of the Windows Media Video 9 encoder/decoder from Microsoft round 2003 sometime.

The WMV9 codec file container (such as AVI)/file header contains interlaced exif compression data in HuffYUV (current OS) as opposed to the AVISTREAMINFO.fccHandler, and was officially supported by Windows 2000, Windows 98 Second Edition, Windows ME, Windows NT and the Windows XP OS/s.

Being a depreciated legacy API from Microsoft, it could be an issue with how Windows 8.1/MakeMKV calls the API when saving/encoding file. (I know nothing about how MakeMKV uses its API/format profiles by the way and could be totally in the wrong)

[Bri1270]

My thinking may not be 100%, per codec ID: Codec ID : V_MS/VFW/FOURCC / WVC1, and the running OS: Windows 8.1 x64 bit system.

I conclude:

The .m2ts container format used for multiplexing the audio/video of your movie with MakeMKV does not contain the proper interlaced exif data and probably just needs an alternate container. (probably)

Video Compression Manager (VCM) is a version of the Windows Media Video 9 encoder/decoder from Microsoft round 2003 sometime.

The WMV9 codec file container (such as AVI)/file header contains interlaced exif compression data in HuffYUV (current OS) as opposed to the AVISTREAMINFO.fccHandler, and was officially supported by Windows 2000, Windows 98 Second Edition, Windows ME, Windows NT and the Windows XP OS/s.

Being a depreciated legacy API from Microsoft, it could be an issue with how Windows 8.1/MakeMKV calls the API when saving/encoding file. (I know nothing about how MakeMKV uses its API/format profiles by the way and could be totally in the wrong)

Thanks Again k4sh1n. I suppose I could try to re-encode it and see how it works. Not a huge deal.

[Bri1270]

ok, so last night I checked this:

KODI>system>audio output>keep audio device alive>(change to always)

It was already set to always. I tried re-ripping FoD, and no luck. I tried all of my HDDVD rips and they all have the same issue. They will play fine from the beginning, but if I stop them and try to resume, I get audio only but no video. Field of Dreams is the only title with audio issues. I'm going to buy the Blu Ray for that one. Aside from being a niggling problem and my severe OCD, it shouldn't really be an issue since most of the time I watch something all the way through.

Is there anything I can download for Windows 8.1 that could potentially help?

[k4sh1n]

I'd guess encoding with a different program to H.264 format to leverage a more current codec.
I personally use handbrake to remux files

[Bri1270]

I'd guess encoding with a different program to H.264 format to leverage a more current codec.
I personally use handbrake to remux files

That's my next step.