Recent update = video studder
#16
(2015-03-03, 07:42)nickr Wrote: First rule of media players, if it ain't broken, don't fix it!

It is a server first and foremost, all security updates all the time. It also sits there so I also use it to play media while it's CPU is doing nothing else. Still if an update is the issue, the team needs to know/figure it out. This is not my HTPC.

(2015-03-03, 07:42)nickr Wrote: And your subtitle problems should probably go in another thread.
There are at least 3 threads in the past. I think one of them at least were even deleted. All ended with 'We are working on it...' and that started many years ago... around version 10.

(2015-03-03, 08:44)FernetMenta Wrote: http://kodi.wiki/view/HOW-TO:Install_Kod...ment_build
Sweet, thanks. But it'll take longer then hoped. I literally have slept twice since my last post with work overload. Only just took a break to catch up. I did do a few logs with different drivers in the meantime though on the standing build. All with the exact same results accept the video driver information was different each time.

Watching the debug tracker on the top, it's also using all 6 cores to about 15-20% and it never goes beyond that. Total CPU usage is roughly 115-125%. (if it used all 6 cores to load, it would be 600%). No core is close to being utilized and the chip isn't even running warm.

(2015-03-05, 19:17)Ectholian Wrote: You might check if fgrlx isnt installed. I had it a few times after upgrading ubuntu that it installed fgrlx (sigh)..

Thanks, but at least with the server installs of Ubuntu, then adding desktop, it doesn't do that. I would have to forcefully add that particular driver cause it isn't even in their library to begin with, at least in the server package... Even after adding desktop. I don't actually use their 'desktop' version so that might be different...

If I reformat again, I'm also going to try gnome desktop instead of ubunbu-desktop if by some off-chance. Worst case I just let it run on windows next to that machine and leave desktop off it altogether (or at least for KODI, everything else works just fine...). Although those machines don't use the internal player either, MPC-HC and PowerDVD instead.

But AMD's driver hasn't been on since two reformats ago. (I love reformatting Linux... 20 minutes, run my setup script for the server stuff (nothing desktop at all) and it's off an running and no-one is the wiser). I've been carefully watching that bit. Still again, even if it was doing everything software, so would everything else be and KODI is the only issue. Plus the CPU is far more then capable... And it's like once every 5-15 minutes, not once every few seconds...

I might get some time tonight or tomorrow to do more testing though. At my current test results, it's entirely dependent on the UPS being plugged in. I'm going to look for other UPS tracking software also to see if it is the default package that is what is stepping on KODI (or visa-versa). But I would still think it would show up in other more sensitive videos, I.E. FLASH which tends to be the worst of all, but it runs smoothly. Will report back when I get something...
Reply
#17
Well, I had 10 minutes to kill so off a fresh format I loaded Kodi, installed the open source driver and tried a clean attack at it with everything clean. I do admit, CPU usage went from 15-20 down to 7-20 (some still up but a few cores down), but that didn't change the end result at all. EXACTLY when it happened this popped up:

Code:
10:17:28 T:140312764712704   DEBUG: CDVDPlayerVideo::CalcDropRequirement - hurry: 1
10:17:28 T:140312764712704   DEBUG: Previous line repeats 8 times.
10:17:28 T:140312764712704   DEBUG: CDVDPlayerVideo::CalcDropRequirement - hurry: 0
10:17:28 T:140312764712704   DEBUG: CDVDPlayerVideo::CalcDropRequirement - hurry: 1
10:17:28 T:140312764712704   DEBUG: Previous line repeats 6 times.
10:17:28 T:140312764712704   DEBUG: CDVDPlayerVideo::CalcDropRequirement - hurry: 0
10:17:28 T:140312764712704   DEBUG: Previous line repeats 3 times.
10:17:28 T:140312764712704   DEBUG: CDVDPlayerVideo::CalcDropRequirement - hurry: 1

Maybe that is the result of lines above it... dunno, the remote window watching the log wasn't very big. But the files are on the local RAID array with disk speeds of over 800M reads and 600M writes. And this problem doesn't exist on any other system reading the same file even though that's dropped down through 1G (110M Max) network. I also did a full reboot and did it again to make sure... So CPU usage is nicer sure, but the problem remains exactly the same...

New logs of all events accept the original. I went ahead and un-tar/gzip-ed them and just ZIP-ed them in windows... Habits. I'm used to tarballs. But here's the zip file of the new logs:

New Logs

I still haven't tried the nightly yet. That's next. Sorry it's taking so long, that's the nature of my job unfortunately. I'll try to do that yet soon.
Reply
#18
Does the same file work, when ripped to mkv (just raw ripped via makemkv)?
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#19
MKVs do the same thing in the default player on this system, that's why they now use VLC on that system. For that matter, that's one reason why all of my systems use external programs for all the playing, accept iso's on this system. But MKV's do the same thing. And I made an MKV of this particular video without any issues either to put it on my phone. It plays fine as does the iso on other systems via PowerDVD or WinDVD.Everything relates to the default player of KODI. Nothing else shows the issues...
Reply
#20
There is much more in kodi (filesystem for example) that seems to cause this issue here. Can you please post a log with the mkv?

So in fact that iso file works with VLC? (Edit: through kodi)
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#21
The file system is a 24TB RAID6 array with a local read speed roughly 800MB/sec. And it has never been any issue before and is no issue with other tools (VLC). The boot drive is an SSD.

No, VLC does not have the temp video freeze issue seen here with ISOs.

I have to remove the playercorefactory.xml. I was here actually to get the link for doing the nightly build. Work has been insane with the ongoing company merger. This is the first chance I've had since my last post. And I work at home, from a wheelchair. I don't go out, etc. Can't drive anymore, no car, etc. I work, eat and sleep. So literally this is the first chance... Sorry for the delay. I don't have a lot of time today but I'll try to get that log instead. The pause is shorter but still obvious. I think it still relates somehow to the UPS functions. But then still, why just this program?!? Back in a bit I hope unless work snowballs again.
Reply
#22
Wow, that was fast. I just picked one I knew was already .mkv... 20000 leagues under the sea, the original... it did it before the credits even rolled through.

Code:
11:48:09 T:140547317827328   DEBUG: Thread JobWorker 140547317827328 terminating (autodelete)
11:48:09 T:140546924324608   DEBUG: Thread JobWorker 140546924324608 terminating (autodelete)
11:48:09 T:140546957895424   DEBUG: Thread JobWorker 140546957895424 terminating (autodelete)
11:48:09 T:140546932717312   DEBUG: Thread JobWorker 140546932717312 terminating (autodelete)
11:48:29 T:140548167571392    INFO: LIRC Initialize: using: /dev/lircd
11:48:29 T:140548167571392   DEBUG: Failed to connect to LIRC. Giving up.
11:48:39 T:140546320344832 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
11:48:40 T:140546320344832 WARNING: Previous line repeats 12 times.
11:48:40 T:140546320344832   DEBUG: CDVDPlayerVideo::CalcDropRequirement - hurry: 1
11:48:42 T:140548167571392   DEBUG: Previous line repeats 7 times.
11:48:42 T:140548167571392   DEBUG: ------ Window Init (Pointer.xml) ------
11:48:42 T:140548167571392   DEBUG: ------ Window Init (VideoOSD.xml) ------
11:48:45 T:140546320344832   DEBUG: CPullupCorrection: detected pattern of length 2: 33333.27 50083.40, frameduration: 41708.333333

I also tried a remote file (I have some other .mkv's on a 12TB ZFS2 remote system...) just to take the RAID array out of the loop, just in case...

Code:
11:53:35 T:140276868413376    INFO: LIRC Initialize: using: /dev/lircd
11:53:35 T:140276868413376   DEBUG: Failed to connect to LIRC. Giving up.
11:53:39 T:140275024385792 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
11:53:40 T:140275024385792 WARNING: Previous line repeats 25 times.
11:53:40 T:140275024385792   DEBUG: CDVDPlayerVideo::CalcDropRequirement - hurry: 1
11:53:40 T:140275024385792   DEBUG: Previous line repeats 5 times.
11:53:40 T:140275024385792   DEBUG: CDVDPlayerVideo::CalcDropRequirement - hurry: 0
11:53:40 T:140275024385792   DEBUG: Previous line repeats 8 times.
11:53:40 T:140275024385792   DEBUG: CDVDPlayerVideo::CalcDropRequirement - hurry: 1

To be honest, it happened faster with the .MKVs. I've gone a bit on ISOs before it hit, MKVs hit really fast. FWIW... Might be coincidence though.

This system used to use the internal player for everything for convenience, even with the subtitle problems. But now it uses VLC for playing .MKVs cause it works properly. I've watched every single James Bond this week while working from Dr. No to Skyfall that I had ripped previously in .MKV format from the blu-ray through VLC without a single hickup.

I'm going to unplug the UPS and do more testing today as long as work keeps calmer. It is a CyberPower BRG1500AVRLCD for future reference plugged in directly using the default power systems of Ubuntu Server to monitor without additional software. Works great on the UPS side, even did an unplug and wait for power down test successfully, and no playback issues on any other systems or this system's software other then KODI (I keep typing XBMC...). But if it's related, it would help to know.

Both Log Files
Reply
#23
Please don't post cut logfiles and zip logfiles. One never knows what is in there. There is a higher chance someone will look at the logs if you post them on xbmc.logs.com
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#24
(2015-03-14, 10:16)fritsch Wrote: Please don't post cut logfiles and zip logfiles. One never knows what is in there. There is a higher chance someone will look at the logs if you post them on xbmc.logs.com

I do hope your joking.
  • Malware can come in any flavor and any file format. If I wanted to be malicious, i could do it in a text format just as easily as an exe format or zip format. It is all about trusting the user. But if all of a sudden, now, you think I'm trying to damage your whatever, by all means run away screaming. Be my guest...
  • Heck, running security, I've seen basic TEXT files that can be put into a server which attack a vulnerability within specific browsers even... So clicking the link itself and the damage is done. And that's not even going into more complex Java (which is why it's now generally disabled as a default on most reliable browsers) or even just scripting languages. As with everything on the net, know where you're going and what you're looking at. I have no reason to do anything malicious but the files will stay safe(er) in my control.
  • It would be just as easy to upload a malicious file to any site and likely even more effective to put it in a public area. That would accomplish nothing. Regardless of where the file comes from, it is the responsibility of the user to test any and every file before opening it.
  • I'll keep them on my private server where they are safer and where I can delete them when they are done since they do contain information that could potentially be used to penetrate one of my servers. Even just a good user name can be enough help to finish the task. I also group the relevant logs together in one file so you don't have to click a dozen links. This also helps slow down bots from sniffing public files for information that we don't want to reveal. And THAT is a higher-chance I'd like to avoid... If you don't think it's a prime target for such information gathering... wow...
  • I posted the relevant part of the log that triggered during the event. The same part we have been discussing this entire two pages so far to save time opening any files unless you're looking for something else, in which case the files are there, for now, enjoy.
  • It took two pages and two weeks for this to even be an issue? Do you have anything more relevant to contribute? Other suggestions or thoughts? For that matter, I don't have the time to investigate even the abilities of xbmc log's storage, (really, they go through the trouble of changing the name and don't do it globally?) ability to delete or not, etc. Most people on the net do not have a safe, private server or service to put images, files, etc. and have to use unwanted services like postimage or photobucket, etc. in which case some private log place is convenient for them. Not always the case.

In the end, it's all about the user. If they intend to be malicious, it's really not hard to do so. And if they are the malicious type, then they generally have the knowledge to do so. If these were from a private, onsite the home HTPC, that might be another story, but not a server that is also connected, in any form, to the outside world. With many TB of untouched ISOs of my private movie collection, attempts to pirate it wouldn't be the first time. If that was even the most benign action. There are those who'd love to see it all destroyed for their own amusement. No thanks. Not to mention other possible information on that system... And the attempt-hit counters on my security services are enough to keep me alert.

And besides, I don't think the logs are going to tell us at this point (problem is here). They only show the symptoms at this point. KODI isn't working well with other system jobs it seems in the case of this setup. I don't think it's going to show in the logs. And for what ever reason, KODI is the ONLY affected piece of software... That itself, is the actual issue. But to figure out which part of it that is could take a lot more time then I have.
Reply
#25
You want help, post your logs as requested by one of our best developers and bug fixers, or quite simply go the hell away until your attitude problem is fixed.
If I have helped you or increased your knowledge, click the 'thumbs up' button to give thanks :) (People with less than 20 posts won't see the "thumbs up" button.)
Reply
#26
(2015-03-14, 20:24)nickr Wrote: You want help, post your logs as requested by one of our best developers and bug fixers, or quite simply go the hell away until your attitude problem is fixed.
  • You assume attitude where there is none. I had meant attitude in the one post earlier in this thread and that moment has passed. I'm autistic (Aspergers, though they decided to un-name it for what ever stupid reason...) so for me to convey an expression is extremely difficult when I don't really have any of my own and can't see them on other people standing right in front of me.
  • Help is what I'm offering, not seeking. I've identified a flaw in their software. We've now confirmed it has nothing to do with the video drivers or file format or location. But for my personal use, it doesn't matter. I use external software. Still they deserve a resolution and since I have an easily accessible/formatable/etc. server which I can rebuild the boot drive in 20 minutes, I have been testing various ideas and possible solutions. None yet successful. For me to do that, I have to take my 'working' version offline (remove the playercorefactory.xml file).

As I stated already, I use external players for many reasons, this is one of them. Subtitles have been noted and been 'in progress' since version 10 that I'm aware of.

I also found problems with the scraper that were confirmed and noted for developers to address. Even what specifically needs to be fixed in the scraper. To my knowledge they haven't been fixed yet although I haven't checked the nightly.

As a media display system, it works just fine. Accept for the for-mentioned scrapper issue which is supposedly in the channel to be fixed. I haven't used the built-in player for quite a while for the subtitle issue alone. I noted a more rare issue that has since been determined to be a combination of issues that XBMC itself is susceptible to for whatever reason. If they don't want to address or look further into it, that's their choice. But again, as I said in the last post, that level of information most likely isn't going to exist in the log anyhow.

I noticed a problem and let them know. What they do with it is up to them. It doesn't affect me either way. I assumed, perhaps wrongly, that they want to make the best and most solid product they can. Assuming that, here is one small conflict that needs attention and it seems to come up with this particular setup. Even with fresh formats, etc. The logs are going to be removed in another week or two or if we find a faster resolution. Another developer asked me to check the nightly which I haven't had the time yet to perform but I'll get to it next week. Tomorrow is looking to be yet more work overload. Seems to be the norm lately.

Perhaps this was already found and addressed in the more recent engine... perhaps... I'll find out when I can spare half an hour to load up the new nightly and give it a test.

I use it for displaying the media. I use it on many different systems. When I notice something I mention it. When I have needed assistance to understand (actually, at the time find the specifics in) the wiki to figure out proper changes to the mouse, keyboard, home files, etc. It was easy to get. As a developer myself, I know I want my products to be second to none, I want everyone to tell me of every tiny issue in every remotely possible setup combination. That's the information I need and I provided. But this seven minutes has delayed me now I need to return to work. I type fast sure but... I'll try to get to the nightly as soon as possible.
Reply
#27
Well if you are so keen to help then post the requested log to a paste site.
If I have helped you or increased your knowledge, click the 'thumbs up' button to give thanks :) (People with less than 20 posts won't see the "thumbs up" button.)
Reply
#28
It is not about malware but about time. I stepped by multiple times here but did not find a quick access to a log. As a result I go to the next thread where users seek for help too. We do this in our spare time which is limited. If you pastebin your logs those are easy to access. I can give the link to another dev and point him to a particular line. Donwloading zips is inconvenient and won't be done.
Further, if you think the problem is in the code, please use latest development version as I already requested. I don't remember the exact behavior of a version a couple of months old.
Reply
#29
(2015-03-15, 03:59)nickr Wrote: Well if you are so keen to help then post the requested log to a paste site.

I explained that quite simply and clearly last time... Security is paramount...

As well, the logs have since been removed now anyhow. There is no relevant information within them for this problem. If they choose to ignore it, that is their issue, not mine. If they insisted on more public paste-bin log postings, they should be more careful to strip out all identifying information (user names, etc). If I had yet another server, I'd do a blank install for just testing and then post the log on the moon for all that matters. I only have 8 current computers/servers and they are all in use for various tasks. This server is my most unneeded one (well, the most unneeded one that still has a monitor to pull this off regardless).

The problem directly links to how the system interacts with the system and the task that monitors the state of the UPS on the default Ubuntu Server installation. I haven't tested 'alternate' UPS monitoring software as the default works perfectly well and I'm doing this on my 'spare' time of which I have almost none lately. I clocked 122 hours last week alone. With sleep, food and especially my family of 4, and do everything from a wheelchair, that's no leftover time (and no life for whatever that is worth...). I've explained right where the issue lies and how to replicate it.

And I did finally get to test the nightly, unfortunately that made ZERO difference... Same exact errors in the same way... The only solution is to remove the UPS (or find other software which I haven't been able to yet. This is the first 10 minutes I've had since my last post).

The only other thing to say is that nothing else has this problem. Not even Flash video; Not VLC, Videos, PLEX, Nore any software that remotely uses those same files. Only KODI live on that system running the built-in player and only when coupled with a UPS on the default power monitoring software with Ubuntu Server. And it only causes a pause of about 1/2 - 3/4 of a second in video, audio doesn't skip a beat. It's not driver (or at least trying 4 vastly different drivers made ZERO differences), CPU, or disk speed related as we've obviously proved all of those.

You guys had thoughts of more common 'problems' with people's setups. This isn't one. This is a problem with whatever the server is using for these tasks. Ping the UPS for a power report and it blips the video. Unplug the UPS and it's smooth sailing. Something is stepping in toes. I use VLC all the time anyhow as that fixes subtitle issues that still exist.

If I get more time, I'll see if CyberPower has a special LINUX monitor software package like APC does... But who knows when I'll get more spare time. I worked right through my and my wife's birthdays. I don't stop often. I have to leave now though cause it's time to take one of the boys to the Dr's. I was doing this before that. But so rarely do I even get into a car anymore. Upside/downside of working out of the home.

And I'd be more apt to be more helpful if proven items got fixed. I.E. the scrapper still doesn't order them properly in the example shown above... Unless we have to completely purge the files or something (though tried that once too a bit ago, no joy then, maybe now.. dunno.) But regardless, unsubscribing from this thread. I've done what I can unless I run into a new solution with other software, then I'll post it.
Reply
#30
Presumably if you don't want the devs help, we won't hear from you again. Can't say that will disappoint me, or I suspect, anyone else.
If I have helped you or increased your knowledge, click the 'thumbs up' button to give thanks :) (People with less than 20 posts won't see the "thumbs up" button.)
Reply

Logout Mark Read Team Forum Stats Members Help
Recent update = video studder0