I have another imx6 device, the same as vero, running libreelec, no choppy video… Now I use my expensive vero 1 without media center service, but only for mysql and other little network services.
I have released Kodi 17.2 for all platforms: Vero, Raspberry Pi and AppleTV.
I understand that Kodi 17.x may not provide the same playback performance as v16, but this is being worked on.
I’m not ignoring @leurb, I simply missed the notification.
I wanted to reply yesterday, but simply couldn’t because of the security issue affecting Kodi that needed dealing with.
I have replied to every question and post in this thread and will continue to do so.
We looked in to this in April and we are still working on things. I will post progress, and test builds, as we get there.
The issue has occurred with the new VideoPlayer in Kodi v17 and the rewrite of the IMX decoder. The IPU can manipulate frames in one pipe sync to one clock for a specific resolution. If we exceed this, the frame is split in to 2 or 4 frames, which (with the new VideoPlayer code) are split with the intention of being processed as parallel pipelines.
The redesign was done with the GC2000 (i.MX6 DL+ or above) in mind, but Vero 1 features a GC880 (i.MX6 DL). The choice of GC880 in Vero was judicious. There are bugs in sillicon with other models and we consulted with the SoC manufacturer (Freescale at the time) regarding this, but details are for another day.
It is clear however, that VideoPlayer and the iMX6 implementation of it has been designed with the GC2000 in mind.
Your other device is almost certainly not ‘same as Vero’.
It will be using a GC2000.
Keep in mind OSMC contributions to i.MX6’s LibreELEC platform. Even recently .
So what the hell are we doing about this?
There is not much point in plastering over the issue or bodging things temporarily. We should fix them properly so that Vero serves you well in to the future and beyond.
- We’re improving things.
- Making sure 1080p playback works properly by:
- Development of VDOA approach. This is a synchronous transfer from VPU to IPU which doesn’t involve any memory copying or CPU load. Furthermore, under some circumstances we’ll be able to skip the IPU: if there’s no need to deinterlace or resize. This means we can move from VPU to framebuffer within 1ms. With no VSYNC needed in this scenario, we’d be able to achieve 1080p60 playback, despite the memory bandwidth. 1080p60 is something we didn’t advertise with Vero 1, but we will be able to do it with this new scheme.
- Development of ring buffer approach. We need to split IPU tasks in to a circular buffer for the best performance. This is being worked on. It works but it’s immature, and trust me, I’ve learned from that lesson…
- Making sure 1080p playback works properly by:
- We will review future versions of Kodi more thoroughly. I published every Kodi beta for Vero 1, but it’s clear a lot of testing wasn’t done by users. That’s not the fault of users. In future, I think we should race to the finish line less, and simply refuse to release a new version of Kodi until a certain portion of users have tested the new version. The fact is that if we hadn’t released Krypton yet, we’d have very few complaints, despite the fact that Jarvis is still (and will continue to be) available on our website for this platform.
- I’m now hiring people to look after things. The fact is OSMC has grown far beyond a hobby now, and there are too many responsibilities in the day. I can’t handle all the activities anymore and don’t want to compromise. It’s time to grow things and grow people, so that everything can get the full attention that it deserves.
People have always suggested that I keep them more informed and I agree that it’s something I don’t always do correctly. The problem is that sometimes I think something can be done within a certain timeframe, so I think a reply isn’t necessary until it’s done. But when other challenges pop up, I don’t always communicate as quickly as I could to inform people that things are delayed. I’m working on that.
This will benefit all platforms including OSMC and LibreELEC. LibreELEC is doing a good service in serving the wider iMX6 community by providing them with images. I also believe we have a great duty to provide a performant reference implementation (Vero) of iMX6 for them to follow. This will then trickle down to other platforms and devices, including LE devices.
But it pains me when someone suggests that I’ve abandoned the Vero 1 users or forgotten about them. I haven’t.
Everyone using these Vero 1 made OSMC what it is today. I won’t forget that. Conversely, I don’t want to bullshit anyone and say it will be fixed by a certain date. The harsh reality is that it’s going to take time to get things in to shape. Use Jarvis if you must, but be assured that there will be a working Krypton.
sorry, my bad
Thanks Sam - as a existing Vero1 user appreciate your honesty here and intent to improve under the hood.
sorry team osmc, but this has become “a bit” of a farce - getting close to the 6 month anniversary for this bug rendering the vero 1 useless…
There are a variety of improvements in the staging repository. If you would like to test them I can give some advice.
Jarvis will work at this time if you want to wait for someone else to confirm the improvements
Is there a special release to try or should we just update to the latest official OSMC version?
So, is there something we can/should test?
Those being interested should get some instructions then.
The builds are in the staging repository (jessie-devel)
sorry but see me as a simple Vero end user.
Me (perhaps also others) would need some instructions or a start thread which explains how to install such a build onto our Vero device.
With thx in advance,
It’s from another thread, but the idea of staging is the same:
Many thx for this hint, followed the three steps to update to Krypton v17.3 with jessie-devel.
Mediacenter afterwards is shown as
Unfortunately it doesn’t change anything towards the choppy/stuttering videos: I used movies ‘Equals’ and ‘Man lernt nie aus’ (‘The Intern’). Demo clips already provided to you.
@sam : the problems with the vero1 and 1080p content where now more then 150 days ago posted.
A lof of research, testing and explaining has been done but no resolution.
I see a lot off fixes for de vero 4k every monthly update and I get it that the focus lays there but as mentioned earlier vero 1 users where your first supporters .
Almost 6 months I can’t watch 1080p content and the workarounds are no solution for me (back to kodi 16 is a lot of work because I have a mixed environment (RP1) and shared database).
So is it time to say goodbye to the vero 1 ? because we can’t wait for ever.
Is there an ETA on a solution with kodi 17.4 or later ?
Is it ever going to be fixed ?
Please let us know so we can make a decision ?
Did you try the latest update? Did it have no positive effect?
Updated this morning to 2017-07-01 and watched this afternoon new 1080p content and no change.
Also had a video still and a sad face today on the Vero.
Please post a debug log of the still and sad face, as not aware of a reason for that
Sorry, to get in this again. I’m also losing hope that there will be a fix for the classic Vero for this issue anymore.
Although Sam said so often that there will be a fix for the classic Vero+Krypton, we do not see any activities regarding this, no information updates, nothing.
@sam_nazarko: Will there be any special discount for classic Vero users for a new Vero 4k? I would like to get rid off this subject, since it frustrates me more and more. In case this cannot be fixed anymore by insuperable hardware constraints what about to offer interested classic Vero users a special price as “business solution”?
Indeed, thx pointing out my fault.
The stills and the sad face ocure very randomly.
Sometimes twice a day and sometimes days nothing.
So creating debug logs from these issues is not simple (as far as I know).
The stills and sad face I can live with because a restart of the video fixes it.
The issue with the choppy video is much more frustrating because the video is not watchable.
Can we first fix that (or get an ETA on this) ?