Playback issue with Mezzmo transcoding

[Paul]

As I mentioned previously, we tried all sorts of tricks, but nothing really worked. For example, if we overestimate, the device may try and ask us for some bytes from the end of the file, but that data doesn't exist, so it aborts playback. I wish it was simple, but it's just not at the moment

Regarding the library layout - I've just tried it here on our Revue and everything seems in order and looks exactly as I have in my Mezzmo library. Can you please provide more details on what you move where and what happens on the device? Please note that some devices cache folders, so you may need to restart the server for changes to take effect.

[pgoelz]

Yeah, the Revue is an unfinished work in progress.... or at least I hope it is still in progress.

Nothing is simple these days. Seems to me that lately, every time a manufacturer makes things "simpler" they get more complicated unless you happen to think exactly like the manufacturer did. File sharing worked just fine for me. I'm assuming that doing it the DLNA way has some advantages like security and playback smoothness, but it also adds a new level of complexity.

I have uninstalled and reinstalled to totally wipe and reinstate my library. So far, so good. I'll let you know when/if I run into additional inconsistencies. Here's what I have.... how should things work?

I have an MP3 folder and a Photos folder on one partition. I have two entire hard drives with videos. I originally added them each tp the library and specified what kind of files each contained. That worked OK as far as I could tell, but I would occasionally find inconsistencies trying to browse the folders (which is how I have to browse the video files since they don't have metadata and their file names are simply serially assigned). More as I find it

Paul

[Paul]

Yes, DLNA solves some issues (e.g. support for files larger than 4GBs on FAT32 USB sticks), but it does add complexity, mostly because transcoding is not well defined in the specs and thus it's up to firmware player developers and server (like Mezzmo) developers to invent things and squeeze them into an existing framework.

Your setup sounds fine, let me know if you hit any issues.

[pgoelz]

OK, after some more experimentation, I have two possible issues but the first is possibly actually a Revue issue.

This morning I was browsing through my files on the Revue. At first, everything was where it should be. My two video drives were in the "folders" folder within the video folder on the Revue. After running into issue two (below), suddenly I had the following when browsing on the Revue.... Mezzmo > video > folders > U:, G: (my two video drives) > U: > video > folders > U:, G:. In other words, there was a second video > folders nested inside the first one. I told the Revue to re-scan after resetting the media server (see below) and everything reverted to being correct.

The second issue seems to be some sort of bug or unexpected behavior in the Mezzmo media server. If I watch the CPU usage on the server PC (Win7 Pro, x64, C2Duo, 3GHz, 4GB) as I request playback on the Revue, when I attempt to play a long file (especially AVI files) the CPU goes to 100% as expected and the file does not play (still transcoding?). I have the "complete transcoded files in the background" UNchecked, but if I abort the playback on the Revue, the CPU stays at 100% indefinitely instead of going back to zero. If I look in the transcoded files folder, there is one that is still growing in size. This then seems to corrupt the next playback (and/or causes the incorrect folder display behavior) and has resulted in the media server actually shutting down a couple times. If I stop and then restart the media server, I can usually restore proper behavior but the trouble is that unless I am watching the CPU usage, I don't know it is happening. The server is not in the same room as the Revue and I have been monitoring it using remote desktop. I have subsequently checked the "complete transcoded files in the background" checkbox and told it to use lower priority CPU.... we'll see if that cures it.

I note that the transcoded files are not as big as I would expect.... they are in the video folder and are named with a random filename that includes the string "aac" or maybe "ac3". Are these actually just audio files? Is that perhaps the only thing that Mezzmo needs to transcode? I have seen some references to the fact that it might be the audio in MTS files that makes the Revue barf..... my MTS files don't take anywhere near as long to transcode (and at lower CPU utilization) than AVI files.

Paul

[Paul]

On a rare occasion I've seen the Revue request invalid data, and I suspect that's what's causing the strange folder display. I am not sure when the Revue starts doing that, but possibly there's something in their firmware that gets confused about something. It's hard to reproduce though...

We'll check that transcoding issue - if you have background transcoding turned off, then the file should be stopped and deleted shortly after you stop playback (within 30 seconds, I'd say, but could be up to 2 minutes).

There are several folders in the transcoding folder - one for Video, one for Audio, etc... So, if a file is in the Video folder, then it's a video. They may be larger, smaller or similar to the original, depending on the input and output formats and whether it's a remux or a full transcode. MTS are more likely to get remuxed and thus be quicker and less CPU-intensive than AVIs, which are rarely remuxed.

[pgoelz]

Well, that explains much, I think. I'm pretty sure at least a couple times I waited at least 2 minutes after beginning a transcode and aborting to see if it stopped, but I'll make sure tonight. What I expected it to do was stop immediately. And that also explains why it is far more likely to stall on AVIs since they seem to take almost real time to transcode. Plus they are bigger to start with. I'll experiment and let you know.

Paul

[Paul]

Transcoding doesn't stop immediately, because we don't know if the device will continue requesting the file or not (there's no indication from the device to us saying that you've stopped playback or that it can't play the file). So, we basically timeout when no requests come in after a certain period of time and move transcoding to the background (or stop it).

[pgoelz]

Case #1
"Complete partially transcoded files in background" is CHECKED
Requested playback of 10 minute AVI file.
Transcoding started after several seconds and the CPU went to 100%.
After 10-15 seconds (playback had not yet begun) I aborted the playback attempt by hitting the HOME button on the Revue.
CPU remained at 100%.
I then used the Mezzmo GUI to stop all current transcoding and Mezzmo confirmed that all transcoding had stopped.
CPU remained at 100% until I stopped and restarted the server about 6 minutes later.


Case #2
"Complete partially transcoded files in background" is UN-CHECKED
Requested playback of 11 minute AVI file.
Transcoding started after several seconds and the CPU went to 100%.
After 10-15 seconds (playback had not yet begun) I aborted the playback attempt by hitting the HOME button on the Revue. Note that at the 5-8 second point, the CPU went to zero and then back to 100%. Not sure why.
CPU then remained at 100%.
I then used the Mezzmo GUI to stop all current transcoding and Mezzmo confirmed that all transcoding had stopped.
CPU remained at 100% until I stopped and restarted the server about 4 minutes later.

####################################

It occurred to me that if you cannot duplicate this behavior, it is very possible that the Revue does not tell the server that playback has stopped and it no longer needs the file.... so transcoding continues until it finishes? Trouble is that if you start several playbacks without letting any complete, the server can apparently get tangled up and crash or shut down. Possibly because the CPU is at 100%?

Paul

[pgoelz]

Sorry, took so long typing that last that I got out of synch. OK, I can certainly see how transcoding might not stop if the server does not get a cancel from the player. Can I set the timeout shorter in the profile? I'll have a look.

Paul

[Paul]

No, that timeout is set at 2 minutes and cannot be changed at the moment. We'll need to make it adjustable, really, so I'll add that as an option in a future update.