I am using MiniDLNA 1.0.25 on ReadyNas Duo with firmware RAIDiator 4.1.10.
For the M2TS files that I have, MiniDLNA is putting incorrect values in the DETAILS table for DLNA_PN and MIME columns.
Analyzing the sqlite3 database file shows DLNA_PN="" and MIME="video/mpeg" for my M2TS files.
On my Sony BDP-S590 player, I see these files as MPEG files. When trying to play the files, the Sony BDP-S590 complains that the files are corrupt.
I created these M2TS files by using tsMuxer to convert MKV files to M2TS.
I do have a workaround this issue.
To fix this issue, I manually update the sqlite3 database with the following command:
update details set dlna_pn="AVC_TS_MP_SD_AC3_T", mime="video/vnd.dlna.mpeg-tts" where path like "%.%M2TS"
My Sony BDP-S590 player is now able to play these M2TS files.
I guess I'm hoping there will be a fix for this so that no sqlite updates are required.
It's not a great solution, but you could add that command to a cron job that runs daily or hourly.
The only m2ts files that I seem to have to do this for are h.264 video with mp2 audio (these are MPEG2 SD files that I have recorded from my TV tuner, then re-encoded the video, but not the audio). MiniDLNA seems to work fine with AVCHD type m2ts files (i.e. h.264 video and AC3 audio) and my Sony TV.
Yeah, I just noticed it too. If the M2TS file uses AC3 audio, MiniDLNA has no problems recognizing it as a M2TS file.
If you look at the value of DLNA_PN="AVC_TS_MP_SD_AC3_T", you see the AC3 part. I'm not sure if this is a DLNA standard value or just something MiniDLNA uses internally. It appears to be a DLNA standard value.
So if your M2TS has audio in another format like DTS or AAC, then it seems MiniDLNA won't recognize your file mime-type as M2TS. And hence, it resorts to MPEG.
I'm not certain that there are any DLNA standard values outside of the mandatory set. For video, that means MPEG2 with either MP2 or AC3 audio.
Beyond that, the DLNA consortium resorted to the chocolate fireguard approach as far as I can see - basically everybody extends exactly how they like - meaning that the CE manufacturers make up a DLNA_PN that is unique to their products then forget about any form of interoperability. The server authors then have to mess about supporting multiple DLNA_PNs for the same file.
I can only go on the functionality of my Sony TVs, in that they only support AVCHD m2ts files with AC3 or MP2 audio, and for the latter I have to fix it with a DB patch cronjob. This is presumably because the TV does not support DTS audio, although given that it does support AAC via USB connection, there's little reason whey this shouldn't work.
I should probably add that this is with my 2009/2010 TVs. I've not revisited this with my 2012 one.
I'm using a Sony BDP-S590 blu-ray player which was release in early 2012.
It has no problems playing M2TS with AAC 5.1 channels either through USB or when I hack the MiniDLNA sqlite database using the update command I posted. I've got it hooked up to my sound system through HDMI, so it converts the audio to PCM.
I started having problems with my M2TS videos with AAC audio when my Sony BDP-s590 was recently updated to the latest firmware. The latest firmware seems to have made the BDP-s590 client DLNA app *stricter* in regards to respecting the metadata sent from MiniDLNA. Before the latest firmware update, the BDP-s590 must have just ignore the metadata sent from the MiniDLNA if it did not match the actual metadata in the video file it was receiving.
Playing the same M2TS file through the USB port works fine. Hence, why I suspect that MiniDLNA sending the mimetype value of "video/mpeg" the BDP-s590 through the DLNA protocol is messing things up.
Just another update. The sqlite update command doesn't require a value
DLNA_PN to be set. Just the mime-type needs to be set properly.
So, new update command is:
update details set dlna_pn="", mime="video/vnd.dlna.mpeg-tts" where path
I'm guessing this suggests that MiniDLNA should default to setting the mime
value for M2TS files to "video/vnd.dlna.mpeg-tts" instead of "video/mpeg"
whenever it their is an unrecognized/unsupported audio codec.
It used to be necessary to manually set the DLNA_PN as a workaround, but a major rewrite of the client recognition code now dynamically assigns this based on the client to maximise device compatibility. Looks like this dynamic choice is based on MIME type in the DB. I don't think that the server sends the MIME to the client, only the DLNA_PN.
Setting the DLNA_PN without changing the MIME type still works for me though. I'm not sure why!
Using the below will catch .m2ts and .ts files.
update details set dlna_pn="", mime="video/vnd.dlna.mpeg-tts" where path like "%.%TS"