Some files refuse to play at correct AR, S5100

[DenyAll]

Just to clarify about using the 2013 profile...

Yep, that's what I picked up on - which suggests your device will play most MKV's without transcoding. Where I was coming from with my comment is that imho it's always better to play the file natively (which the 2013 profile does) than to transcode (which the 2010 does) if you can.

So the better approach to my mind is to use the 2013 profile, and then address those files that don't play or stutter by transcoding only them (rather than all MKV's), after identifying what makes them different (I suggested the DTS audio, but perhaps not). But this is just an opinion , it's totally up to you (and in any case, I think the process jhb50 is helping you with is essential as there seems to be something amiss with how some files were encoded).

ps. another thing you could try is the Panasonic Viera (2010) profile - this adds black bars to the top and bottom... interested to see if it "de-stretches" your stretched videos.

I wouldn't even know how to begin to edit a profile so it plays only certain mkv files, other than switching the profile back and forth everytime I ran into one. Which I'd rather not do. When the 2010 profile transcodes all mkvs, the playback is near instantaneous like I said. When the mkvs are not transcoded with the 2013 profile, playback takes up to several minutes to start while you stare at a black screen, and then it might decide to kick you back to the movie list instead of actually playing it. I would think transcoding should take awhile for playback to start so the 2013 profile should be the one with the near instant playback, but it's not. If all things were equal, yes, I'd definitely prefer no transcoding, but that long wait for the movies to start playing is really annoying to me.

I just tried the Panasonic Viera (2010) profile, and the movie stays scrunched into 16:9 but forces the black bars on all 4 sides of the movie. But with that odd sizing, I can then change the TV display to Wide Zoom and it ends up displaying perfectly without cutting off the sides. It also forces the 16:9 even on the movies that played with correct AR. But like the 2013 playback, it's very choppy and unwatchable. That profile also doesn't seem to play any avi files.

But by accident I was on the Generic DLNA profile afterwards and oddly enough that plays all the movies with the correct AR and without any stuttering at all. It doesn't transcode the mkv files either and their playback starts up just about as fast as with the 2010 profile. In testing that profile more, I found a few random avi files that are 16:9 but would display smaller with the black bars on all 4 sides. But a quick change of the TV display fixes that instantly when it happens. I think it happens when black bars are actually part of the file, I generally prefer to remove them and not waste the bits on black areas.

I'm going to stay on the generic profile for awhile and see if it really works out better than either the 2010 or 2013 Sony profiles.

[jhb50]

the tradeoff was that other older mkv files wouldn't play at all. Or they would take forever to start playing where you'd wait over a minute of a black screen not knowing if the movie would eventually start or you'd be kicked back to the movie list. With the 2013 profile, there's very few times any transcoding takes place for most files, so I would expect it to be faster playback, not slower. Using the 2010 profile that will transcode all the mkv files, it's near instant playback even on the largest of files and without any stuttering at all.

With the 2010 profile, your Spock and Khan mkv files are only being remuxed to mpegts with the existing v/a streams copied, which will play immediately. Since there is no 2010 rule to treat h264 > 4.1 differently I have to assume the player can handle them.
With the 2013 profile , your mkv files are either played as is, or if h264 > 4.1 the video is transcoded to mpeg2video which will take time depending on your pc speed. A 2013 debug log showing the playback of these files along with their ffmpeg output and the observed problem result would be needed to determine what Serviio is doing and the cause of the problem for each file.

One set of problem movies for me is the Star Wars Despecialized Editions under the 2013 profile, they take forever to load and then will playback with very bad stuttering, if they playback at all. Although one of those movies, The Empire Strikes Back, only plays in the scrunched 16:9 under the 2010 profile for me and no matter how I re-encode it, I can't get that fixed.

Again without a log and ffmpeg output for each ....

I fail to understand why you are using handbrake. You said above that you are trying to eliminate the black bars "HandBrake just removes the black useless borders". This makes no sense to me because if the movie is AR=2.40 it has to have black bars on a 16:9 AR=1.78 screen, and I'm sure the h264 encoding rules do not takeup "bits" for the black bars since it is designed to minimize the file size.

I use HandBrake to rip the movies from the bluray to an mkv file, and it just happens to do it without including the black bars as part of the mkv file. Where I mentioned removing the black bars from the video, it was in response to atc98092 when he noticed his copy showed a width and height of 1920x1080, and mine showed 1920x808. His copy of the movie included the black bars as part of the file, mine did not. Of course you'll always see the black bars on the TV screen since they're all 16:9, but you don't need to increase the file size by including those black bars in the mkv file, I just meant they're not part of the file itself.

The Despecialized version of the movies have the 2 SAR/DAR values (and not ripped by me, so I'm apparently not the only one that happens to). I just can't figure out a way yet to re-encode it so it has only 1 value there. That would solve the problem.

Edit: Even though I haven't been able to eliminate the 2 SAR/DAR values for that particular movie, once I removed all but 1 audio stream and 1 subtitle, the Generic DLNA profile is starting it almost instantly now. It will also start the original with everything in it in about 25 seconds, so even that's an improvement and I'm going to stick with this profile for awhile, it's definitely better than the 2013 profile for me and doesn't transcode any of the mkv files.

Now to figure out why Serviio 1.5.2 is using up to 98% of the CPU, even when neither player in the house is on.

[DenyAll]

The use of the Pansonic 2010 profile and more so your subsequent Generic Profile tells us a fair bit. You could probably modify the Sony BDP-Sx100 (2013) profile (edit the Serviio\config\profiles.xml file with a text editor like Notepad ++) to work for you (add the bits in red - this will comment out these lines):

<!--Matches container="*" vCodec="h264" profile="high" levelGreaterThan="4.2" />
<Matches container="*" vCodec="h264" profile="main" levelGreaterThan="4.2" / -->

After saving the profile you will need to restart the Serviio service (or your PC).

The advantage this will give you over the Generic Profile is that it will transcode codecs that your device doesn't support (eg. H.265, VP8). Having said that:

• You probably don't have any H265, High_10, VP8 video's... so the above is more if you come across these video formats in the future;
• Given that your PC doesn't seem to transcode video well - which is why it's slow to commence playing transcoded videos (rather than remuxed) and accounts for the stuttering - even if you do get some H265 video's you may not have the grunt to transcode them on the fly.

ps. I know you said you wouldn't know where to start with editing profiles, but it's not hard. The profiles are written for a range of devices (in this case the whole Sx100 series) and therefore tries to cater for all devices in the range. Sometimes, as is the case here its seems, this means it transcodes where it may not have to.

[DenyAll]

Now to figure out why Serviio 1.5.2 is using up to 98% of the CPU, even when neither player in the house is on.

• Have you recently been transcoding (the transcoding process wont stop until it is finished, or you start to transcode video from the same device, or restart Serviio.
• Is it still indexing your library (check the log file for lots of "INFO [MediaFileIndexer]" records).

The 98% utilisation will also account for the stuttering and slow startup of videos (mine starts instantly when not transcoding and after a few seconds normally when transcoding and my server is an old Core 2 Quad).

[*]Given that your PC doesn't seem to transcode video well - which is why it's slow to commence playing transcoded videos (rather than remuxed) and accounts for the stuttering - even if you do get some H265 video's you may not have the grunt to transcode them on the fly.[/list]ps. I know you said you wouldn't know where to start with editing profiles, but it's not hard. The profiles are written for a range of devices (in this case the whole Sx100 series) and therefore tries to cater for all devices in the range. Sometimes, as is the case here its seems, this means it transcodes where it may not have to.

No, it's actually just the opposite. Under the 2010 profile, the PC does indeed transcode every mkv file and playback starts up almost instantly and is smooth throughout the movie, even for files that are 10+GB. Under the 2013 profile, the PC does no transcoding at all of mkv files, but that's the profile that can take several minutes for playback to begin, or after the long delay, it will just pop back to the movie list. If it does play, it's very choppy and the movie is unwatchable with no transcoding.

But after re-encoding the problem movies leaving only the English audio streams and English subs, even the 2013 profile starts up just about as fast as the 2010 profile. Those movies had up to 38 different subtitles and over 20 audio streams. It still seems odd though to me that the transcoded movies under the 2010 profile will play back quickly and without so much as a hiccup even with the large number of audio tracks and subs included, and the 2013 profile that does no transcoding has the problems of extremely slow playback and bad stuttering. One thing it allows that the 2010 profile doesn't though is changing the audio track during playback under 2013. I can live with re-encoding a few files that the 2013 profile will choke on though for that, plus I discovered the Generic DLNA profile won't playback the really oddball files like .flv. I don't have many of them, but it's nice to keep the option to play them. I'll make that change to the profile though and see if it helps any so avoid having to re-encode any files, that would be ideal.

As far as the CPU usage climbing up to 98%, it's not related to any of this (pretty sure any way). I have 2 PCs that I run Serviio on, so if I'm using the main PC for something, I don't get any lag while someone is watching movies. And during all the playback tests above, I was careful to watch the CPU usage and restart Serviio if it was creeping up too high. You can easily tell because the entire system becomes very sluggish and unresponsive, but I've been keeping the resource monitor visible to keep an eye on it to be sure it's not the cause of any of the above problems.

My main PC, Windows 7 Pro 64-bit, is wired to 1 Sony player that all of the above was tested on (the player connected only with wifi can't playback the very large files without stuttering, it does playback up to 4GB files without any problems though with the 2010 profile). Processor is an AMD FX-8320 8-core, so there really shouldn't be any lag on playback, especially when not doing any transcoding. The 2nd PC is older, WinXP SP 3, processor is AMD Phenom II X2 550 2-core, but still plays back everything except the 10GB files very smoothly and playback starts instantly.

Since upgrading to 1.5.2 though, both PCs will eventually just stop doing anything until I turn off Serviio completely, stop the server and close the console, because ServiioServer.exe is using up to 98% of the CPU. This happens on a fresh reboot, start up the server and console, and never starting either of the players at all. So there's no transcoding that's been done that might continue happening in the background, there should be nothing but updates to the library if necessary. I have all online metadata retrieval turned off. But within 2 hours or so CPU usage will be at the 98% point for Serviio.

I've tried completely uninstalling Serviio and reinstalling it several times on both PCs, no change. I've added Serviio to be excluded from my AV program, even tried it with AV turned completely off. Last week I finally decided to try and go back to 1.4.1.2 on the WinXP machine (I know that version was working well on both PCs) to test it and CPU usage for Serviio never gets very high at all even while watching movies from it that are being transcoded. The problem instantly went away on the slower PC.

Will the Serviio log files tell you anything when no movies are being played at all? I still have 1.5.2 on the Windows 7 PC wired PC for any testing. I didn't mention this before because I really don't think it's related to the Sony players at all or playback or profiles, and thought it would probably be better asked in the general support section after getting the AR issue straightened out. And as I said I always kept an eye on CPU usage while doing any of the tests for this thread, I never really left Serviio running long enough for it to start to be a problem, I turned it off between testing.

[DenyAll]

It still seems odd though to me that the transcoded movies under the 2010 profile will play back quickly....

No, it's readily explainable:

• the 2010 profile doesn't transcode the video, it simply remuxes all MKV files to a mpeg file. The remuxing process is quick and doesn't use much CPU, but you do lose things - embedded subtitles, multiple audio tracks and you may experience issues with seeking;
• the 2013 profile has a few transcoding statements (two of which impact - as per my post above) that result in some MKV files having their video transcoded. Video transcoding is slow and CPU intensive (and is causing issues in your environment, but still not sure why). My last post suggested removing these two commands (by commenting it out) which should work for you, but up to you whether you stay with the Generic Profile, the modified 2013 profile or go back to the 2010 profile.

Me, I would modify the 2013 profile as that should play your MKV files natively, while still transcoding those odd FLV files (and others that are not supported).

CPU Usage

Not sure but you may be right - it may be better to start a new topic. There are two things that changed in 1.5 that could be impacting:

• the way the library is updated. Try turning off library updates for a day or two to rule that out (Turn off "Keep Library Automatically Updated" on the Library, Shared Folders tab).
• The use of Java 8, which is now deployed with Serviio.

and yes, a detailed log file may show the cause. Is any of your media on a remote drive?

I guess I got it wrong about when transcoding happens. I assumed when a transcoding-temp-xprofile.stf file was created that Serviio was transcoding; and if there's no stf file created, it's not transcoding. That assumption must be wrong then per what you're saying. And yes, I'll definitely try editing the 2013 profile as you said. It doesn't take days for the CPU to spike, only a few hours. Right now since my last post it's up to 67% and both players have been off.

I do have networked drives usually connected between both computers just to be able to reach all files without changing servers. But I removed them from both PCs as one of the things I tried, and there was no change, the CPU usage still hit high numbers doing nothing until the PCs were unusable. I also tried turning off library updates and just stuck to manually updating the library and again, no change.

[jhb50]

I assumed when a transcoding-temp-xprofile.stf file was created that Serviio was transcoding; and if there's no stf file created, it's not transcoding.

That assumption is correct, however the transcoding may simply be a remux by copying the existing elementary audio and video streams into a new envelope like mpegts, or it may be the cpu intensive decode and reencode of the existing elementary streams to a new codec like avc/h264 to mpeg2video prior to putting them in the new envelope. You need to see the ffmpeg command in the debug log to determine what type of transcoding occurred.

you don't need to increase the file size by including those black bars in the mkv file

This assumption is incorrect. The purpose of the various codecs is to compress the actual bits (1920x1080 or 1920x800) to the smallest possible size. That means the black bars will be simply be encoded as 'xxxx black bits from location x1-y1 to x2-y2' rather than 'black bit location x1-y1'' nnnnn times thru "black bit location xnnnn-ynnnn" , which means the 1920x1080 file will not be any larger than your 1920x800 file, which is why I questioned the need to use handbrake rather than a simple ripper.

The Despecialized version of the movies have the 2 SAR/DAR values (and not ripped by me, so I'm apparently not the only one that happens to). I just can't figure out a way yet to re-encode it so it has only 1 value there. That would solve the problem.

I would assume that this was also ripped using the same parameters that gave you 2 values and caused the raw file to play full screen on your player. Maybe running these files back thru handbrake with the strick value would work.

I assumed when a transcoding-temp-xprofile.stf file was created that Serviio was transcoding; and if there's no stf file created, it's not transcoding.

That assumption is correct, however the transcoding may simply be a remux by copying the existing elementary audio and video streams into a new envelope like mpegts, or it may be the cpu intensive decode and reencode of the existing elementary streams to a new codec like avc/h264 to mpeg2video prior to putting them in the new envelope. You need to see the ffmpeg command in the debug log to determine what type of transcoding occurred.

So is it correct then if there is no transcoding-xxxx.stf file created, Serviio is not doing any remuxing or transcoding?

you don't need to increase the file size by including those black bars in the mkv file

This assumption is incorrect. The purpose of the various codecs is to compress the actual bits (1920x1080 or 1920x800) to the smallest possible size. That means the black bars will be simply be encoded as 'xxxx black bits from location x1-y1 to x2-y2' rather than 'black bit location x1-y1'' nnnnn times thru "black bit location xnnnn-ynnnn" , which means the 1920x1080 file will not be any larger than your 1920x800 file, which is why I questioned the need to use handbrake rather than a simple ripper.

I've always read it's best to have your ripper of choice remove those black bars. In fact I don't know of any ripper that leaves them in any more, and I've been trying out quite a few recently. What I've read about it is that it takes higher CPU use to transcode the areas where the black bars meet the picture, or it can leave fuzzy edges. Whether or not it's really noticeable, I have no idea, because even the files I might download like the Star Wars Despecialized versions have the black bars always removed (edit: actually only 1 has them removed, the 2nd one has them).

The Despecialized version of the movies have the 2 SAR/DAR values (and not ripped by me, so I'm apparently not the only one that happens to). I just can't figure out a way yet to re-encode it so it has only 1 value there. That would solve the problem.

I would assume that this was also ripped using the same parameters that gave you 2 values and caused the raw file to play full screen on your player. Maybe running these files back thru handbrake with the strick value would work.

No matter what settings I used, I always ended up with the same 2 SAR/DAR values. I was going to try other rippers but then found other downloads, and these new files do not have the problem, so I gave up on trying to eliminate it by re-encoding.

I've been using the 2013 profile (with those 2 lines commented out as suggested) the last couple of days, and there's really not much difference in how it performs. One of the files that used to take about 2 minutes to start and then played too choppy to watch now takes over 5 minutes to begin playing (no .stf file was created for whatever that means), and when it did finally begin to play, it was smooth... but only for the first 8.5 minutes. Then it became choppy and unwatchable again. I really don't mind having to re-encode a few files here and there though for the extra benefit from the 2013 profile, so I'll stick with that one for now.

Still getting nowhere about the high CPU usage though, and I'll post in General about that. I thought I had an idea (I always keep UPnP and SSDP disabled), and renabled SSDP to see if that mattered. It seems to have helped a bit, the CPU usage only gets up to 77 or so after a few hours and not 98, but that's still not acceptable and never was a problem with 1.4.1.2.