Kodi Community Forum

Hello, I've tried Frodo on Win8 and 12.2 xbmcbuntu. So far both of them yield me blocky pixelation on every movie. It seems to happen most on moving objects or when scenes change. I think i've tried every permutation of settings under Video and VideoOutput

Motherboard: ASRock Z87E-ITX
CPU: i3-4130T Haswell 2.9GHz
RAM: 4GB ddr3

Does anyone have any ideas on how to fix this? Could it be my hardware? My videos are all in x264 1080p with a bitrate of 10-15kbps or so. I've spent hours of searching and haven't come up with much other than it appears to be called MacroBlocking.

You need to get the latest driver from here- Automatically identify and find drivers...

If you still having issue, you can try to disable "Allow hardware acceleration (DXVA2)" and select "Software" as Render method in XBMC system/settings/video/playback....

I agree with bluray, you should definitely check if you're using the latest drivers. If not, then uninstall them =>reboot (to be on the safe side) and install the new drivers.

If this doesn't help then it would be good to know if this happens with all your movies? If they're all encoded/ripped the same way then I'd try running it through VLC or another media player to check if you have the same issues.

Hi bluray. I had actually read one of your prior posts a few weeks ago that linked that same site. I had gone through the process on my win8 machine but it didn't find an updated driver. I had tried working with the win8 install for many weeks. I ran for a bit with dxva2, a bit without it, and i believe i tried software, but i'm not positive on that one.

Today i wiped the win8 and went for 12.2 xbmcbuntu. I just tried the intel graphics update but the page just spins forever on "analyzing computer...". I left it to spin (it never stopped) and went ahead with downloading the 4400 driver manually. Sadly, I'm unable to install it since the installer depends on libglib2.0-0=2 and the highest that ubuntu 12 seems to be able to get is 2.34.1. Googling for a bit seemed to indicate that Intel drivers are auto-updated via ubuntu, though i'm a novice at best with ubuntu so i'm just taking other's words for things in regards to it.

While i continue troubleshooting with this xbmcbuntu install, do you mind if i ask which OS would be preferred? I own a copy of Win8 and Win7. Or, if ubuntu is more desired, should i install xbmcbuntu or do a typical ubuntu install with xbmc post-installed?

To assist with searching.. does my problem appear to be MacroBlocking or is it something else?

(2014-03-22, 04:44)nooryani84 Wrote: [ -> ]happens with all your movies? If they're all encoded/ripped the same way then I'd try running it through VLC or another media player to check if you have the same issues.

Yea, it is happening with every movie i try. It will often go spans of 15 minutes or so without pixelating. Sometimes it's just a little blip when it changes scenes. Other times it keeps compounding upon itself and becomes unwatchable for 10 seconds or so. The movie never freezes or drops though. I gave VLC a try once and they played fine though it. Another thing worth noting is that i can rewind and replay and it will always pixelate at the same spots in each movie.


EDIT: i just installed vlc on the ubuntu 12.10 system and played the same movie i shared with you on youtube. Turns out that it's having the same pixelation on vlc. I have it shared from a fileserver. I'll try copying it locally to see if that helps, though the machine is currently hardlined to it (it usually connects via 802.11ac).

EDIT2: Just played the same movie on my standard desktop in VLC and it had the pixelation there too. How did i not notice that before? :/ desktop is win8.1, i7 930@ 2.8GHz, GTX 480 SLI (2), 12GB ram. It was playing over the 802.11ac connection.. but i speedtest.net at 80Mbps over it and i can only assume the local connection to my fileserver is faster. The file is still copying over to the ubuntu's local drive.

(2014-03-22, 05:44)btarb24 Wrote: [ -> ]Hi bluray. I had actually read one of your prior posts a few weeks ago that linked that same site. I had gone through the process on my win8 machine but it didn't find an updated driver. I had tried working with the win8 install for many weeks. I ran for a bit with dxva2, a bit without it, and i believe i tried software, but i'm not positive on that one.

You seems to have issue with driver more than anything else. If you cannot update the driver through driver auto detect option, you can download the latest driver manually too- Find By Category....

If you are not using Windows, I cannot help you on it because I use nothing but Windows....

Thanks. On my win8.1 machine i just updated to the latest nvidia drivers and i still get the problem when playing over network. I also finished copying the file locally to the xbmcbuntu machine and played it on vlc. Both systems still have the pixelation.

Does anyone know what that pixelation in my screenshot and video is technically called? This is seemingly difficult to search for to find out more troubleshooting steps.

So you have pixelation on 2 different PCs with different OSes and different players?
Are you sure the video file is not corrupt?

Did you disable the hardware acceleration in XBMC settings?

I ran XBMC on a haswell-pentium (G3420) and a haswell-i5 (4670K)
no problem with pixeling, but enabling the "hardware acceleration" made videos start noticable slower, horrible stuttering, a/v-sync problems.

(2014-03-22, 13:47)tausche Wrote: [ -> ]Are you sure the video file is not corrupt?

No, and after i did the testing last night i came to lean toward that assumption as well. Without going into too many unwanted details, there are about 100 video files, of which i've tried about 40 and experienced artifacts on them all. The source files were acquired via the bittorrent protocol. Other people have played the "same" files without experiencing troubles. Perhaps there's something wrong with my torrent client (Tixati) or my raid server (UnRaid).

I'm about to start researching, but i might as well ask here as well - does anyone know of a way to validate the integrity of an x264 mkv file?

EDIT: I just verified that i can play a freshly downloaded file. Once i copy it to my UnRaid server (with all brand new hardware) the file gets artifacts. I just hashed the local and the stored file to discover they're different. It looks like the files are somehow getting corrupt during the transfer to the fileserver.

possibly it is a problem with the unraid, do you use latest version?
i'm not familiar with it, but I guess there is a possibility to let unraid check the integrity of the data?

format is called h264, x264 is only the encoder, just saying

the easiest "integrity check" would be if you take in in seed again in your bittorrent client,
the client will do a re-hash and download parts if they are corrupt/missing.

another way is to demux and remux the file with mkvinfo and mkvmerge,
I don't know the ubunut package name by heart, but you will find it.

(2014-03-22, 22:02)tausche Wrote: [ -> ]possibly it is a problem with the unraid, do you use latest version? i'm not familiar with it, but I guess there is a possibility to let unraid check the integrity of the data?

I'm using 5.0 and it looks like they've had a few small patches since then and are at 5.0.5 now. I'll try updating and see if that helps with new files. I found this thread on their forum. Sounds like a couple others have recently ran into the same problem.

I have my unRaid set up with a Parity drive and i've had it go through and do a parity check that resulted without error. I'm guessing the problem must be occurring during the saving operation. This is based on the assumption that it wouldn't be during the network transfer since the TCP layer would catch corrupt packets during its crc and request replacements.. right?

(2014-03-22, 22:02)tausche Wrote: [ -> ]format is called h264, x264 is only the encoder, just saying

haha thanks

(2014-03-22, 22:02)tausche Wrote: [ -> ]the easiest "integrity check" would be if you take in in seed again in your bittorrent client,
the client will do a re-hash and download parts if they are corrupt/missing. another way is to demux and remux the file with mkvinfo and mkvmerge,
I don't know the ubunut package name by heart, but you will find it.

Wow, the idea of using the bittorrent client to validate and repair the file is absolutely brilliant! I'll definitely give that a go once i've figured out the source of the corruption.

(2014-03-22, 23:00)btarb24 Wrote: [ -> ]This is based on the assumption that it wouldn't be during the network transfer since the TCP layer would catch corrupt packets during its crc and request replacements.. right?

Right.
The TCP does all error handling because after each TCP-window an acknowledge ("yes, i got it!") is sent from destination to source.
So if something goes wrong during transfer, TCP should ask for the frame again, so no data will be lost.

You're using TCP, not UDP, no?
In UDP you have no error control and a continous data stream -> this is where transport errors could happen.

Assuming that the data is 100% correct at your download-PC, it is most likely that unRaid does something wrong when saving it to the filesystem.
But no "error" in this case, unraid seems to think that the data is correct,
if not the parity check should bring up errors...

So, once again:
After downloading the file is 100% ok and plays without pixels?
After copying it over to unRaid there is always pixelation at any file?

Ok, thanks.
Which BT-client are u using?
for validating, try the following:

Pick a file on the unRaid which pixels.
Add the torrent to your client, but don't download them on you "download-PC",
instead of this you set the download-location to the unRaid (make sure you have write permissions at least on this one file) and start the download.

After the validating/download finishes, start the video file directly from the unraid to see, if there is still pixelation.

(2014-03-23, 10:16)tausche Wrote: [ -> ]You're using TCP, not UDP, no?
In UDP you have no error control and a continous data stream -> this is where transport errors could happen.

As far as i know it's TCP. I was using samba shares and doing a drag/drop copy with Windows. As of yesterday i started using TeraCopy so i can conveniently do a hash check of the resulting file.

(2014-03-23, 10:16)tausche Wrote: [ -> ]After downloading the file is 100% ok and plays without pixels?
After copying it over to unRaid there is always pixelation at any file?

The file I was using to test with last night played perfectly from the download machine, from a VM, and when copied to an xbmcbunto machine. Once i copied it to the unRaid it would have pixelation. If i then copied it back to my desktop from the unraid i'd still get pixelation. I did CRC on the unraid copy of the file and it didn't match my original. I did an additional crc on the same unraid file and its crc hash didn't change, so it's unlikely to be a transport issue.

On a scary note.. I rebooted the unraid last night and got new results (it had only been up since March 8). I copied my same 11gb test movie back onto the unraid server and did a CRC.. it came out clean! I played the movie and saw no pixelation. I played an old movie and it still had pixelation. It's currently hard to tell if the corruption happened during the save process or it happened over time - though i'd think parity would fail if it were over time. Needless to say, i'll be doing CRCs on all copies from now on and i'll be monitoring this test file to see if it becomes corrupt.

(2014-03-23, 10:16)tausche Wrote: [ -> ]Which BT-client are u using?for validating, try the following: ...

Tixati. Though, when attempting to download directly to the file server i noticed it kept wanting to recheck the 13gb file, so i switched to the BitTorrent client for the 'repair' process. Check out this screenshot that shows the hash checks for the same file (top=tixati, bottom=bittorrent):


There appears to be a pattern the corruption and that about 7% was corrupt. After the torrent repair was complete the movie played without pixelation and had a valid CRC against my originally-downloaded file on my workstation.

The 2nd file i went to repair had about the same amount of corrupt slices, but doesn't seem to have any discernible pattern:


and the 3rd file i did had similar percent as well as about the same pattern as the 1st file had.

(2014-03-23, 17:36)btarb24 Wrote: [ -> ]Tixati. Though, when attempting to download directly to the file server i noticed it kept wanting to recheck the 13gb file, so i switched to the BitTorrent client for the 'repair' process.

Not sure if I understand you right, but this 'recheck' wanted by tixati is the repair-process, so there's no need to switch the torrent client?
But nevertheless, if you've done it with the bittorrent client it should do anyway.

All in all, it sounds like there was some data corruption unraid didn't notice,
I also think it isn't a transport problem.
Maybe unraid lost itself somewhere during the uptime and so saved the file 'wrong', but thinking it is 'right'?
Hard to say...

but if unraid had noticed some corruption the parity would have jumped in, which hasn't, so I think the corruption didn't come over time.

Did you check the health of your physical disks, not relying on the unraid-parity-info?
if SMART is active, smartctl should give you infos about defective (reallocated) sector count.

As far as I know unraid uses ReiserFS (3.6?), I have absolutely NO personal experience, always using ext2/3/4 or ZFS
you could use reiserfsck for checking disks (do not run it on the parity drive, but I am aware you know that ;-)

(2014-03-23, 18:04)tausche Wrote: [ -> ]...

Tixati would check the file (10 minute process), download for a few seconds then stop to do a full check again. BitTorrent was less sensitive and would only check the file once. I'm guessing Tixati just struggles with downloading to a mounted samba share.

The drives are new WD nas drives. I left SMART enabled, but it's headless so i wouldn't see any warnings if it had them. Being that UnRaid is a file-level raid and i have similar corruption with files on each disk, i'm thinking it was a software problem rather than a hardware one. Well, i guess it could be hardware, but more likely to be somewhere upstream from the drives, such as the controller. Otherwise i would likely have only experienced select files with corruption since the files aren't striped.

Yea, i had read that unRaid has reiserfs pre-installed. Though, i haven't ran it yet. Beyond the painlessly-easy initial setup and the WebUI i don't have any real experience with unRaid. I didn't see anywhere on the UI to run any checks aside from a simple parity check. The machine is currently headless, so i'll likely hold off and just periodically re-hash the one test file i've been using. This time around i'm keeping all of the torrents in the client after they're complete. That way if things start getting corrupted again i can simply start them all and have a low-effort fix.

I think at this point there isn't a whole lot left to troubleshoot since it's currently 'working'. It would likely be a good idea to run an fs check as well a memtest but, honestly, i don't feel like setting it up at the moment. I'll just monitor the new, crc-verified files to see how that goes. Thank you for all the replies, tausche. It was fun to talk it over with someone and i really appreciate the help

you're welcome.
I know it is a pain if you cannot count on the reliability of your data, and then all help is appreciated.

the headless shouldn't be a problem, you could connect via telnet, ssh or else and get a quick smart output as simple as 'smartctl -a /dev/sdX'
but if you're not striping and the faulty files are on all disks, it is likely no hardware issue...maybe as you said from controller side...but then you will notice very serious problems in short time.

stay tuned and good luck!