Jump to content

playback stuttering with 3.0.5667.6


podrae
 Share

Recommended Posts

podrae

Hi guys

 

I have found that watching anything through the web browser or theater apps is now constantly pausing or freezing completely. This is the case within and outside my network on multiple devices. Server load is nothing and transcode is miles ahead.

 

Didnt seem to be an issue over android device.

 

Anyone else getting similer?

Link to comment
Share on other sites

Salnt23

Yeah, I've been getting the same. I've only really noticed this internally. Transcoding seems to be fine. Server is receiving the movies from another computer inside the network and is receiving and sending plenty fast enough. Networking card isn't overloaded. Same with the router. Not sure what this is.

Edited by Salnt23
Link to comment
Share on other sites

justameinmd

Hey guys I had the same problem directly over my network when I installed Theater recently. I went into the settings for video etc in the tools settings in the upper right where the sprocket is. I adjusted some of those timings & Mbps and it started working. Not sure the exact setting I changed it was a Month ago that I did it but i tried a few things in there and works good now.

  • Like 1
Link to comment
Share on other sites

plazma

Actually I also have this when using 1.5mb with some files. if I play for the start its fine but intermittently if I skip or resume it stutters yet my  pu load is around 80 percent, im also tried with throttling on and of and as ever transcodes set for performance.

 

its not processor overhead and its not disk speed as im using a ram disk for transcode and chrome in diskless cache mode (does the same with chromes disk cache on 2).

 

For me it started about 3 betas back when webm for chrome was dropped, but the fault is very intermittent.

 

Ive been trying to pin down what effects it, thinking it maybe a tweak I made. but its not as I tried with all my tweaks turned off.

 

Interestingly last night when it occurred I had it happen repeated times trying to resume in another room, however instead of a resume I did a normal play and then a manual skip after 10 seconds after the initial playback settled and then it worked.

 

Also once I freaked out (previous beta) the player threw its dollys out and stopped and left me with audio (I assume video was still playing but in the background, which is something I have had in chrome once in a bluemoon, but assumed it maybe because of the tweaks im passing chrome on the command line at launch. However this time when it happened I saw a large emby logo floating in the top left, about 150px square and when I clicked it I was taken to the page for the player plugin that's used where it tells you what browsers it supports (sorry forgot the name) and I cant replicate as I don't know what caused it.

 

But for me at least when I have a stutter only appears to happen post skip (when using resume).

 

Ive not reported as I did believe it maybe my own setup and wanted to eliminate that being the case before I did, but maybe it is a bug if other people have the same.

 

My other thought is that due to the new transcode to multiple ts the interval of the skip appears to occur at roughly the same interval files get generated, I know my processors a bit tight as im only using 67.5% of a low power i3 under a virtualbox, but normally I can hang 2-3 1080p uses off the back without issue. I pondered maybe its the throttle or something having a bit of a hiccup when a new file is written. I know in my case the chips not hit 100%, its not network saturation and as I said its not disk bandwidth. but when it happens if I skip back a min to replay what ive already watch and the skips in the same place, leading me to suspect it maybe happening at transcoder level.

 

I realise im pushing it a little with what my smaller cpu, but the same file can pkay start to end without a hiccup and then occasionally skips after a resume.

 

ive also noticed since the switch away from webm that when playback ends it just sits on the player (were as before it returned to previous page (I think) but this is no issue at all as it doesn't prevent sleep/hibernate from happening on its own, just something else I observed since the change.

Link to comment
Share on other sites

plazma

I do have emby classic for wmc installed on two machines, but recently ive been using the web interface exclusively, in both cases the latest version of chrome, with disk cache enabled or disabled appears to have no effect.

 

The same happens on both a hardwired gigalan machine (servers also gigabit) the other local windows client is over wifi, I even swapped that machine to hardwired and used a wireless bridge for a day to see if it would impact the issue.

 

For me at least the problem is transient, many times resume works fine, but its when I appear to be most likely to see the issue, I have seen it once towards the end of playing back a film, but I cant remember if I resumed on not at that time, I assumed I did.

 

I do have emby on my phone, but the s3's wifi is not the best and the screens to small to comfortably watch anything for very long, im running out of juice, but I will try to replicate on chrome and emby for android tomorrow as im in all day and the battery is on about 10% as ive been stuck on it most of the day lol.

 

For me at least its started after webm was dropped (which did address other minor issues), but it wasn't until after the switch I noticed the issue, but then again its not like I watch the same files each day.

Edited by plazma
Link to comment
Share on other sites

plazma

Ok got some charge in the phone, this Is what I found.

 

Source file 1080p, transcode set at half my normal rate at 720p 1mb.

 

Emby on chrome for android. Prior to dropping webm this used ro work flawlessly, although to get playback to go I used to have to hit play/pause 2 or 3 times. now resume refused to work (as if I didn't click on resume when selected) seek resulted in a ssift crash and video error.

 

Emby on native android app, resume also no does not work here, seek did work, but instantly gave the a far far worse stutter than the desktop, even setting at 480p failed to have any impact.

 

In both cases the file if played from the start works fine.

 

Going back to the desktop, previously in chrome if I hit the close button this would be instant when playing a video now it can at times take an age, the only way to describe it (im not saying this is, but how it reacts on both test desktop systems). If you ever used a windows system low on ram and tried to switch back to something that's been swapped. But like I said its not this as on both systems prior to closing playback task manager reported in testing 50-70% use max (so windows should not be swapping anything) and chrome was all that is running. But this is just a side point.

 

If the skipping on desktop is caused by the same thing its definitely worse by some magnitude on android, so maybe easier to track and find the cause.

 

On the desktop its an annoying skip/stutter/pause ever 15 - 30 seconds (just ball park guess never measured), but I wouldn't say when it happens its consistently x second every time, but per occasion when it does the skip comes at a regular interval.

 

On android it was skipped/hiccupped more than it played, ie less than 2 seconds of play, again the stutter when it occurred happened at what felt like the same number of seconds apart. however on android its so sever its impossible to gauge if its the same at ever event (play back session).

Link to comment
Share on other sites

Well see now I think you might have encountered a problem and are pointing at the easiest possible scapegoat, because you say prior to dropping webm chrome for android worked flawlessly, except chrome for android has never used webm. Mobile chrome has native HLS support so we've always been using that.

Link to comment
Share on other sites

plazma

sorry my mistake, I know it was removed from desktop chrome and wrongly assumed this was the same for android chrome.

 

Ive not used android for any playback since the new player interface for 3 betas back as I said I throught (wrongly) this change also was applied to android chrome.

 

like I said I don't know if the two issues are connected, but when you asked if chrome was the only platform I realised I had not run the same test on android for chrome, so I was mearly reporting back what I found :-)

 

I will reboot the phone in the morning and run the test again on android with different files (only tested with two).

 

This evening on the desktop I had no issues with playback but used resume only once.

Edited by plazma
Link to comment
Share on other sites

plazma

Ok re ran android test and had the same result as above.

 

Its very different fault, neither android client could resume, chrome on android could not skip.

 

However when I replicated the android stutter, if I pause for 10 seconds and play I get roughly 10 seconds of good playback, so unlike when ive experienced the transient error on the desktop, doing the same did not have any effect on the skipping.

 

Im not guessing at the cause but putting the android resume issue aside on android the skip issue appears to possibly client side buffering issues post skip (as shown by the pause allowing it to buffer up and proving its not down to transcode level).

 

On desktop as I said the issue is transient and ive been unable to find a circumstance where I can faithfully replicated it, possibly the other posters can post back some more details to help with this. But as ive said when it happens on the desktop client the skip appears to be at transcode level as a 30 second skip back and replay yields the fault, momentary pause in an identical place.

 

in both the desktop and android clients (again im not connecting the faults and after the above test this would confirm that), but on both clients playback normally for the start and the fault is not evident.

 

 

Second uodate ive just realised the android skip issue, I had tried setting down to 480p 450kbps and it was not actually changing from 720p 1mb, I just kept on stabbing at the setting and it eventually took on the 5th go. This time it skipped ok.

 

But as I said at 720p 1mb I can play for the start and it plays perfectly.

Edited by plazma
Link to comment
Share on other sites

jmgriffes

I've actually run into this issue as well on 3.0.5667.6. Playing from the Web Client (local LAN to the server), my playback will stutter and skip around. I did find that this only seems to occur after I have paused/resumed the video (I can reliably reproduce this). Stopping the video (ie, killing the transcode) and resuming the video clears up the issue until I pause/resume again.

 

This is on Chrome, which is all I've ever used for playing via the web client. Web Client playback had been working perfectly fine before the update to 3.0.5667.6.

Link to comment
Share on other sites

I've actually run into this issue as well on 3.0.5667.6. Playing from the Web Client (local LAN to the server), my playback will stutter and skip around. I did find that this only seems to occur after I have paused/resumed the video (I can reliably reproduce this). Stopping the video (ie, killing the transcode) and resuming the video clears up the issue until I pause/resume again.

 

This is on Chrome, which is all I've ever used for playing via the web client. Web Client playback had been working perfectly fine before the update to 3.0.5667.6.

 

how long do you pause for to reproduce?

Link to comment
Share on other sites

jmgriffes

how long do you pause for to reproduce?

 

It happens whether I pause for a few seconds (talking to someone quickly, then resuming watching my show), or for a long period of time (going to cook dinner). The stuttering does not always happen immediately after I resume, but the show will reliably stutter during playback, and most often skip as well.

 

In fact I just replicated the problem. The stutter happened within 2 minutes of resuming the playback.

Edited by jmgriffes
Link to comment
Share on other sites

Jardex

Hi Guys,

 

I also experience the same problems...It started around v.3.0.5667.6...Using the web client in Chrome...after resuming it works okay for a couple of minutes then the video starts stuttering and finally halts to a grind...changing the quality does not help.

Link to comment
Share on other sites

plazma

Im just wondering (sorry thinking) out loud, why Im seeing this problem less or more sporadically than others is due to my ram disk transcode folder, sadly due the emby vm lives on a drive currently with heavy disk io at times and doesn't have the bandwidth to really remove the ramdisk to see if it makes the issue change (more prominent) without it... but there must be a reason why for me at least why the problem is more transient and this is all I can think of.

 

Can other people count the number of seconds between skips, is it consistent, ie skips plays ok for x seconds and then skips again, does bit rate change the time between good playback and then skips?

 

Also what drives are people using for transcode (local magnetic disk, ssd, ram drive)

 

I was thinking last night, due to the way the new desktop transcode system works its creating numerous ts files, as most of us are using NTFS this will likely create additional overhead due to what ntfs writes out to the file table, in comparison FAT32 would far less overhead in such situations (in the same way you can tweak ext4 in Linux to reduce disk io and thrashing on memory sticks and ssd's) it may worth a shot and have an impact. NTFS writes out / thrashes the disk a little more because of added security flags, ok it causes less fragmentation, but on a ram disk that's no issue.

 

NTFS writes out things like where did the file come from, this is used for thing like the is it safe to run this file, where as a file generated locally (not downloaded) wont have the security prompt, to work around this in the past I just move programs onto a fat32 partition to strip away all the ntfs extra stuff before packaging the program, then when its unpacked the other end NTFS doesn't have the warn about every executable nag.

 

Ive reformatted the ram disk to FAT32, I just stabbing in the dark here, but its worth a go and will report back if it has an effect, like I say im just guessing at this point.

Link to comment
Share on other sites

why don't you just move the transcoding temp folder to another location? transcoding is cpu bound, putting it's temp files on a ram disk isn't going to have any benefit.

Link to comment
Share on other sites

plazma

It has a big difference, ram disk it never hits the physical drive (which has slow io) I know the data being generated shouldn't hit the disks limit, but as the drive is being used for other purposes outside the vm and the head is already skipping back and forth for other things, throw multi emby user transcodes on top of it and the drive starts to fit. Transcoding to the ram drive removes my bottle neck.

 

Every time a new file is created, windows has to generate all the security and stuff for the NTFS header, ffmpeg then writes into the file, emby then reads from the file and serves to the user, for most on a standalone system it wont be an issue, but for me im asking a lot of the drive before I even bring emby into the mix :)

Edited by plazma
Link to comment
Share on other sites

Right i'm saying use your ram disk for normal server data but put the transcoding temp files elsewhere, since that process is going to be limited by the cpu anyway.

Link to comment
Share on other sites

plazma

Sadly the other stuff outside the vm can be done in ram, the only choice ive got currently until I have time to start pulling drives and upgrading 2tb disk for 4tb drives ive ran out of drive bays and sata headers is to move the transcode folder into ram :-(

Link to comment
Share on other sites

if the ram drive will struggle with large numbers of small requests then it will probably be slower for emby use to be honest. and i'm not just talking about playback, i mean everything.

Link to comment
Share on other sites

plazma

Question does the new beta Version 3.0.5675.0 do anything to address the issue, I just tried last nights android test post update an nonmore issues on emby for android app post skip @ 720p 1mbps where as last night it would do it every time.

 

Resume didn't work still on android (but im sure you know this already) also had a bit of a fight to get it to change back from 480p to 720p whilst the video was playing, it did eventually take tho.

 

Sorry want to confirm again the android skip issue is / was very different to the desktop issue, again just following up on what I found before.

 

I don't think its the ram drive struggling with small files, like I say im having the issue less than others.

 

I do have a theory but want to see if im right and using a fat32 form on the ram drive has an effect before I make a guess :-)

 

Additional :The return from player at playback end is now also fixed in the latest beta, also resume now directly jumps instead of play then jump to point :-)

Edited by plazma
Link to comment
Share on other sites

plazma

Ok ive eliminated it being one thing I suspected (which is good and like i said it was only a wild guess), i had to try very hard, pauses, skips across the last few hours and eventually i got it to skip.

 

This time (although i had done the same before) i did a resume and then a skip.

 

However i noticed something very interesting when it did....

 

Look at the time codes (attached image).

 

Could this be what's causing it, i know previously there were issues at times with tike codes getting messed up (ive seen it happen occasionally).i was just about to close and relaunch and noticed the time code.

 

 

Update, ok no resume, no skip and I was getting light skipping/stuttering, until the stutter after pause resume which for me its more like someone paused and then resume.

 

I managed fo rdp to the server just to see the main emby process trying to chomp various level of cpu (I assume indexing new data) and sucking it away from ffmpeg. I have monitored before with the pause resume skip issue and never saw it use anything and no guide scan was happening on the times ive seen it and been monitoring. but like I said it wasn't the same sort of thing.

 

Then I realised both the main emby process and ffmpeg was set to lowest priority, I sort of understand setting emby lower than normal, but surely both on lowest is wrong. Surely setting emby to lowest and ffmpeg to normal would be better. I made the change and ran a scan during playback and problem gone.

 

Like I said this is not the same as the type of regular interval heavy skip I saw previously on play pause so I wont say the two are the same bug/issue, but the light stutter due to emby scanning media and cataloguing new stuff is no more.

 

I may throw together an script to monitor for ffmpeg and elevate it up to normal every 60 second to see what impact it has.

 

Again just reporting what I found.

 

Update 3: ok the 60,second ffmpeg monitor and elevate so far ive been unable to get any skipping at all so far.

 

However ive discovered why my bit rate wouldn't take, at some point the profile had become hard set at 420kbps (despite 2 clients operating at 2mbps. I altered this to 2mbps on the profile and now switch works as expected.

 

Side note, as I said if I kept on jabbing the option it would actually take after a few attempts (surely this shouldn't be possible). Also would it not make more sense for this to work in a similar way to how it works in live tv (ie doesn't display all settings), ie it wouldn't display anything above what the profile restricts to. So set at 1mbps I shouldn't be able to see anything about 1mbps. Just a suggestion, sorry if its already been made. At least that explains away my bitrate set issue.

 

Update 4: Not sure if its a combination of the last update and my elevator script for ffmpeg but ive been using emby so far today in the background while working, lots of skips, pauses and other than the initial wobble after play start (also before the elevator picks up the new thread) but ive had perfect playback.

 

If anyone else on this thread who is suffering still if you wants to test (just to see if it helps you as test only) I would be happy to provide the vbs code im using to see if it works. I don't want to post in a public as this is not intended as a long term fix, just for testing only to see if it has an impact in the scope of this thread.

 

Like I say im not going to say its cured all my stuttering issues, and I still don't fathom while it would do anything positive against the pause/skip issue for reasons already mentioned), but for me at least so far im not seeing any issue since putting it in place last night.

post-55440-0-08180500-1436992453_thumb.jpg

Edited by plazma
Link to comment
Share on other sites

jmgriffes

I still have the stuttering issue occurring with server version: 3.0.5675.1

 

If I resume from pause it will often play for some length of time, then the stuttering begins. Sometimes it will recover for a short amount of time, but eventually it completely freezes up and won't play until I have stopped the playback and resumed it.

 

If I never pause the playback I never have the issues.

Link to comment
Share on other sites

I still have the stuttering issue occurring with server version: 3.0.5675.1

 

If I resume from pause it will often play for some length of time, then the stuttering begins. Sometimes it will recover for a short amount of time, but eventually it completely freezes up and won't play until I have stopped the playback and resumed it.

 

If I never pause the playback I never have the issues.

 

thanks. will check into it.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...