V2 various issues

Moderators: Gully, peteru

Post Reply
sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

V2 various issues

Post by sonicblue » Fri May 22, 2020 19:55

I'd like to report some issues I'm noticing with the V2 on the latest beta firmware (19.3.20200328)

edit: for solutions to many of these issues see V2 unofficial patch.

1. Tuner randomly drops out, reporting signal strength 0% [SOLVED?]

This seems to happen about twice per day. The main tuner is displaying a channel, not timeshifting or recording, then the image pauses and sound cuts out. The EPG info banner reports 0% signal strength. Sometimes if I wait long enough the signal comes back and things continue as normal. Other times I must zap to a different channel and back again to revive it. While this is happening, my other PVR (Tivo) is displaying the same channel without issue. I've not experienced this issue with my T2 connected via the same antenna cable.

edit: after performing the following, the issue appears to have abated, although longer term testing is still needed:

- Uninstalled EPGRefresh
- Deleted and purged all deleted bouquets (note: to access radio bouquets, press FAV then TV/RADIO)
- Rescanned channels and created new bouquets
- Didn't delete the default bouquets created by V2
- Swapped the antenna cable (same spec as the previous one - RG6 quad shield)
- Swapped the HDMI cable to a more shielded one
- Moved USB 3.0 HDD drive as far away as possible from the V2
- Moved wifi router as far away as possible

edit: after long term testing I still experience occasional dropouts which I can't trace to any cause, during which my other PVR is not affected. However not using timeshifting seems to correlate to less occurrences of dropouts, and dropouts now usually occur when both tuners are in use. One thing is for sure: the V2 is much more sensitive to impulse noise, such as light switches and appliances with electrical relays that cycle on and off, eg. clothes dryers.

edit2: I now believe the issue is not caused by reception issues and is more likely a bug. The issue seems to be triggered when one tuner is recording and another is watching live TV, or after recording has ended on the non-active tuner. In this configuration the active tuner suffers dropouts every few seconds. Manually switching to the other tuner resolves the issue. Switching back to the previous tuner continues to show dropouts. Restarting the GUI does not solve the issue, but rebooting the system does resolve the issue and restores both tuners to full signal strength. Under [Tuners] [Tuner Allocation] I have set "preferred tuner" and "preferred tuner for recordings" both to "auto". This configuration seems to minimise the occurrence of the issue.

edit3: I've since moved the HDD to the USB2.0 port given the linked article about USB3.0 interference.


2. Display mode is randomly set to 60hz when zapping between channels [POSSIBLE WORKAROUND]

This seems to happen about twice per day under typical channel browsing behaviour. It can be avoided by setting the global display mode to 50hz instead of multi, however this would require manually changing the display mode back and forth when playing media files which are typically not 50hz. The workaround I'm currently using is to enter and exit standby to re-initialise the display mode after the issue occurs, however the GUI has a tendency to become unresponsive for a while after this bug strikes (see item 3).

To reproduce, zap back and forth between HD channels until the info banner reports 60hz. Most of the time this will not trigger a display mode change to 60hz, however sometimes it will.

Image

I have also tried adjusting [Skip EDID check] and [Delay time] under [AV Settings] to no effect.

edit: after debugging with log lines in VideoMode.py, it appears that both iServiceInformation.sFrameRate and proc/stb/vmpeg/0/framerate continuously report 60hz (framerate=30000) when the issue occurs. Therefore it does not appear to be fixable in VideoMode.py. The fix would have to correct whatever issue is causing enigma to create the incorrect service information in the first place, which I suspect may be tied to the driver, which only Huawei can modify. It may be possible to make a bodge workaround in VideoMode.py that ignores 60hz if we are watching TV, since we know that all our TV channels are not 60hz. The issue would still affect playback of media files though.

edit2: speculation: I noticed decoder stats are showing fluctuations in the frame rate, eg. when viewing a 1080i 50hz channel, the fps stat occasionally goes above 30fps. If this stat is where proc/stb/vmpeg/0/framerate and iServiceInformation.sFrameRate are being sourced from, that might explain why 25fps is occasionally reported as 30fps.

Image

edit3: breakthrough: proc/vfmw/pts_info appears to report the correct frame rate when the bug occurs. i.e when the 60hz bug is in effect, iServiceInformation.sFrameRate and proc/stb/vmpeg/0/framerate both report 30000 (30fps), but proc/vfmw/pts_info reports 25fps. This means we should be able to fix it in VideoMode.py by using that value instead.

Image

edit4: unfortunately after more testing it seems pts_info still reports the incorrect value within the first 2 seconds of a new video stream. I am currently working on a hybrid bodge workaround that forces 50hz when the source is DVB-T, since our broadcasts are exclusively 50hz, and then re-checking pts_info 2 seconds later only if it initially reports 30fps, since that is the only value it appears to report erroneously. However this may be moot given the myriad other issues with 24hz and 60hz modes.


3. When playing 30fps/60fps content at 60hz, the system becomes unresponsive for up to 30 seconds.

Test clips to reproduce the issue: [1][2]. Not all video files are affected.


4. Frame rate randomly begins to stutter [WORKAROUND IDENTIFIED]

When playing live TV, the frame rate occasionally becomes stuttery and requires re-initialising the video stream to correct it, such as by zapping to another channel and back again, or pausing and unpausing into the timeshift buffer, or opening and closing the media library. I have noticed that VideoMode.py: VideoChanged() coincides with the issue. i.e watching a video stream and then for no apparent reason VideoMode.py: VideoChanged() occurs, and the frame rate becomes stuttery.

edit: it appears this can be worked around by cycling the decoder frame rate via proc/msp/vdec_ctrl to another value and back again.


5. Display mode is unnecessarily re-initialised when using automatic resolution [SOLVED]

This appears to be caused by the global display mode being applied on every zap, prior to autores applying the user specified mode. This does not occur on the T2. Steps to reproduce:

1. Set global display mode to 1080 50hz.
2. Turn on autores and set it to output 576i 50hz as 576.
3. Set the autores delay to a long time (eg. 8 seconds).
4. Zap between SD channels and notice the display mode is first set to 1080p 50hz, then 8 seconds later autores sets it to 576.

This also occurs every time you rewind into the timeshift buffer or press [Next] to return to live TV, which makes timeshifting a painful experience. I have also tried adjusting [Skip EDID check] and [Delay time] under [AV Settings] to no effect.

edit: the issue appears to be that /proc/stb/video/videomode_50hz is being applied on every zap. By updating this value with the new mode in VideoMode.py, the issue appears to be solved. This fix will be included in my upcoming patch.


6. When display mode is set to 24hz, 23.976fps media files are output at 24.000hz

This causes a frame to be repeated every 1/(24-23.976) = 41.6 seconds which can be noticeable in scenes containing motion.
https://bitbucket.org/beyonwiz/easy-ui-4/src/master/lib/python/Screens/VideoMode.py wrote: elif SystemInfo["have24hz"] and video_framerate in (23976, 24000):
new_rate = "24"

Changing the above code to 23 doesn't seem to be an option as that value must eventually be converted to 24 to make it compatible with the available modes in proc/stb/video/videomode_choices, i.e setting proc/stb/video/videomode to "1080p23.976" or "1080p23" has no effect as there is are no such modes.

Another option might be to set proc/stb/vmpeg/0/framerate or proc/stb/vmpeg/1/framerate to "23976", however I get input/output error when trying to write to those values from telnet or Python. I can't find any examples in VideoMode.py or AVSwitch.py where they write to that value either.

On my T2 running the same firmware version 19.3, cat proc/stb/vmpeg/0/framerate returns "23976" and I observe no repeated frames on test content. On the V2 it returns "24000" when playing the same video file. V2 also appears to be outputting 29.97 as 30.00 and 59.94 as 60.00 which will cause similar issues.

edit: proc/msp/vdec_ctrl can be used to explicitly set the decoder frame rate, but unfortunately it appears to ceiling to the nearest whole integer.

Code: Select all

echo setfps handle 30 > /proc/msp/vdec_ctrl		# works - 25fps video becomes stuttery
echo setfps handle 25 > /proc/msp/vdec_ctrl		# works - 25fps stops stuttering
echo setfps handle 24.5 > /proc/msp/vdec_ctrl		# no effect

7. Video enhancement setting "auto flesh" is still active when set to 0 [SOLVED]

Steps to reproduce:

1. In Video Enhancement set auto flesh to 0
2. In AV Settings cycle HDMI HDR type from off > HLG > off (this appears to reset auto flesh to its true disabled value)
3. Pause on a scene with flesh tones
4. From telnet echo 0 > /proc/stb/vmpeg/0/pep_auto_flesh and observe flesh tones get brighter when you hit enter
5. Reset the bug with echo hlg > /proc/stb/video/hdmi_hdrtype; sleep 0.1; echo none > /proc/stb/video/hdmi_hdrtype (note: video content must be playing, not paused, in order for this to work)

It appears this can be solved by modifying VideoEnhancement.py to never write any values to proc/stb/vmpeg/0/pep_auto_flesh. This fix will be included in my upcoming patch.


8. Colour is different after playing back HDR media files [WORKAROUND IDENTIFIED]

After playing a HDR video and then returning to SDR content, the colour is not the same as before:

Image

I speculate it may be getting stuck on HDR colourimetry / tonemapping. To reproduce: 4k HDR test clip.

I don't believe this is another manifestation of the "auto flesh" bug described in item 7, as a screenshot comparison via openwebif shows the colour is different yet again.

A workaround has been identified where cycling the HDMI HDR mode to another value and back again restores the original colour. I will try to incorporate this into my upcoming patch.


9. Colour space reverts to RGB when setting HDMI output mode to 2160p [WORKAROUND IDENTIFIED]

Steps to reproduce:

1. Set HDMI output mode to 1080p 50/60/multi
2. Set HDMI colour space to 444 in both [AV Settings] and [Video Enhancement] (they both control proc/stb/video/hdmi_colorspace, but [Video Enhancement] stores its own separate config value which can cause it to conflict with the config value [AV Settings] uses)
3. Set HDMI output mode to 2160p 50/60/multi
(At this point, the colour space may have already reverted to RGB, however my display doesn't support 2160p so I can't check)
4. Select "no" in response to "is this mode ok?"
5. Note that the V2 is now outputting RGB, but [AV Settings] config value is still 444, and proc/stb/video/hdmi_colorspace is still 444

It appears possible to workaround this issue by cycling the HDMI colorspace to another setting and back again. I plan on releasing a patch in the near future which should implement this


10. Incorrect aspect ratio / cropping with certain media files [WORKAROUND IDENTIFIED]

When playing back SD media files (eg. 720x576, 720x480) which are native 4:3 aspect ratio, i.e not pillarboxed in the source, the V2 does not consistently apply the aspect ratio setting in [AV Settings], causing the video to either be stretched horizontally or cropped vertically. The T2 does not have this issue. In some cases, setting "show 4:3 content as" to "pan&scan" corrects the issue. With other video files, a different setting is needed.

edit: after some more testing it appears a workaround is possible by cycling the aspect ratio setting in /proc/stb/video/policy to a different setting and then back again. The correct setting for 4:3 pillarbox appears to be "letterbox" in /proc/stb/video/policy (which maps to "panscan" in the GUI). I plan on writing a fix for this in the near future. There is also a value in /proc/stb/vmpeg/0/aspect which appears to contain the aspect ratio of the video stream, which brings the possibility of correcting the aspect ratio according to our own rules in case the driver gets it wrong on certain content. Finally, /proc/stb/video/policy2 does not seem to work at all: a 1920x800 video is affected by /proc/stb/video/policy, despite policy2 being the value that is intended to control the aspect of >16:9 content.


11. EPG events missing from graphical EPG and single EPG

This issue seems to be caused by overlapping start/end times between neighbouring events, and has been acknowledged here viewtopic.php?p=184314#p184314 . There was a report that it had been fixed in the latest beta, but it definitely has not.


12. Sharpness setting behaves inconsistently [WORKAROUND IDENTIFIED]

Steps to reproduce:

1. Set global display mode to 1080 50hz
2. Zap to a HD channel and wait 5 seconds*
3. Zap to a SD channel and wait 5 seconds*
4. Alternate the sharpness value between 171 and 172 and notice there is no perceptible effect
5. Zap to another SD channel and wait 5 seconds*
6. Alternate between 171 and 172 and notice 172 now causes a significant reduction in sharpness:

* without using the graphical EPG, which resets the bug if you have "picture in graphics" enabled

Image

This inconsistent behaviour can be reset at any time by either rebooting, re-initialising the display mode, or opening and closing the graphical EPG with preview window enabled. However zapping between SD channels will re-instantiate it.

edit: new observation: playing a HDR video from the media player breaks the sharpness control entirely such that it no longer functions until rebooting.

edit2: a workaround has been identified by opening and closing a window containing a full screen picture-in-graphics copy of the currently playing video, and performing this n seconds after the beginning of every new video stream. If I am satisfied with its reliability and practicality I will add it as an optional setting to my upcoming auto sharpness plugin. Although this does not solve the HDR issue.

edit3: new observation: sharpness control becomes nonfunctional when video content is being letterboxed or pillarboxed by the V2 (i.e proc/stb/video/policy = letterbox and content is a non-16:9 format, eg. 1920x800 2.4:1 or 720x576 4:3 non-anamorphic). The sharpness control functions again after returning to non-letterboxed/pillarboxed content.


13. The 576i output appears to be using incorrect colourimetry

It appears to be performing an incorrect conversion to Rec.601 colourimetry. The result is magenta tinted reds and skin tones, and overly bright greens. The 576p output appears to be unaffected.

Image

According to /proc/hisi/msp/disp1, the HDMI output colourimetry is Rec.709 for 576p, and Rec.601 for 576i. Since colours appear fine with 576p mode despite it outputting 709 when displaying 601 content, I speculate the V2 may be internally converting to 709 as part of its video processing, but neglecting to convert it back to 601 to match the 601 HDMI output colourimetry of the 576i mode (and 480i mode as well).

Thankfully the 576p mode is viable as the chipset's de-interlacer is decent and supports 2:2 detection for both 576i and 1080i sources, which somewhat negates the need for a 576i mode, however its 2:2 detection algorithm is a bit unreliable at times.


14. The HDMI output defaults to the RGB colour space [SOLVED]

The default [HDMI colorspace] setting is "Auto", however this appears to be using the RGB colour space for all content, of which the vast majority is YCrCb and should output as such, i.e [HDMI colorspace] "444". The "420" setting also appears to also output RGB; "422" and "444" appear to be the only modes which don't output RGB. Outputting RGB may cause issues with displays, such as incorrect black level due to RGB often being assumed as "full range", or alternate video processing intended for game consoles or PC's which typically use RGB. A solution will be posted in my upcoming patch.
Last edited by sonicblue on Thu Sep 24, 2020 18:08, edited 156 times in total.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: V2 various issues

Post by prl » Sat May 23, 2020 11:01

1. could also be an intermittent fault in your antenna cabling.

Do not enable 12V output on the antenna unless you have a masthead amplifier that is powered through the antenna cable (I understand that they are rare in Australia). If you have such a masthead amplifier, the 12V out must be enabled for the amplifier to work, if not, it must not be enabled.

Enabling it when it's not needed will do no good, and can cause problems (e.g. an inductive balun or splitter in the antenna feed will present a short circuit to the DC 12V).
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Sat May 30, 2020 03:30

Here is a snippet of the logfile from a tuner dropout, which occurred at 114 seconds after boot.

https://pastebin.com/nGwdLrQT

As you can see this dropout only lasted about 15 seconds.

The key presses were me opening the EPG banner to confirm the signal strength was showing 0% and then rushing into the menu to get the log file's time code for reference.

At the time the dropout occurred, the V2 was the only device connected to the antenna. No recordings or time shifting were in progress, no files being streamed over the network, just a USB 3.0 Seagate 1TB connected and idling and DVB-T tuned to ABC.

As mentioned, I've not experienced this on my T2 or Tivo, so it appears to be a V2 specific issue.

So far I have not experienced the issue when using only tuner B and disabling "background scanning" in [Tuner allocation], however the latter seems to cause issues with the EPG showing a lot of <N/A> entries. I will try again using only tuner B and background scanning enabled.

If using only tuner B solves the issue, should I conclude that I probably have a hardware fault with tuner A?

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: V2 various issues

Post by prl » Sat May 30, 2020 12:38

sonicblue wrote:
Sat May 30, 2020 03:30
The key presses were me opening the EPG banner to confirm the signal strength was showing 0% and then rushing into the menu to get the log file's time code for reference.

There are two bars for signal quality: signal strength (upper bar) and signal-to-noise ratio (bottom bar). Which is showing 0%? It's normal (though annoying) for the internal V2 tuners to display 0% for the SNR.
sonicblue wrote:
Sat May 30, 2020 03:30
If using only tuner B solves the issue, should I conclude that I probably have a hardware fault with tuner A?

It seems possible. Both tuners are in the same "can" on a V2. I'm not sure whether there's any separation of power supply for them that might point to a problem with an on-board regulator rather than the tuner itself.

I'd be asking warkus about it.

The tuning was for 226.5MHz, which is for ABC broadcast channel 12 from Mt Lofty.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Sat May 30, 2020 18:35

prl wrote:
Sat May 30, 2020 12:38
There are two bars for signal quality: signal strength (upper bar) and signal-to-noise ratio (bottom bar). Which is showing 0%? It's normal (though annoying) for the internal V2 tuners to display 0% for the SNR.

Yep, I only have the top bar showing strength; bottom bar is always empty / 0%.

The log file is proving extremely useful - I can leave the V2 on all day unattended and search for "[eDVBFrontend] stateLostLock" and see exactly how many dropouts I had and how long they lasted.

Interestingly I seem to be getting about 40 split-second dropouts over a 10 hour period. I presume these are signal interference, like impulse noise or weather related. From the 10 hour log of tuner B only, I had no dropouts lasting longer than about 0.8 seconds, which is great. I will do the same for tuner A.

Another thing I've done is uninstalled EPG Refresh, in case it was interfering.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: V2 various issues

Post by prl » Sat May 30, 2020 18:47

sonicblue wrote:
Sat May 30, 2020 18:35
Another thing I've done is uninstalled EPG Refresh, in case it was interfering.

Worth trying, but I don't think it's a likely cause.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Sun May 31, 2020 22:07

I think the V2's tuners might also be more sensitive to interference, as flicking light switches on and off doesn't affect my other pvr (Tivo) but does affect the V2.

For today's test I performed the following

  • uninstalled EPGRefresh
  • deleted and purged all deleted bouquets
  • rescanned all channels and created new bouquets
  • swapped the antenna cable (same spec as the previous one - RG6 quad shield)
  • swapped the HDMI cable to a more shielded one
  • main tuner set to tuner A
The log file shows I only had 5 split second dropouts in 12 hours, which is great.

However I'm still a bit unoptimistic as the system was freshly rebooted before the test, and the tuner is only on one channel the whole time. I'm sure that when you start zapping around and opening menus and EPG, the system state becomes more complex with different things in memory, more potential for bugs.

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Mon Jun 01, 2020 23:21

Another possibility is RF interference from the USB 3.0 connector and/or HDD itself.

https://www.intel.com.au/content/www/au ... paper.html

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Tue Jun 02, 2020 09:43

sonicblue wrote:
Fri May 22, 2020 19:55
4. When display mode is set to 24hz, 23.976fps media files are output at 24.000hz

This causes a frame to be repeated every 1/(24-23.976) = 41.6 seconds which can be noticeable in scenes containing motion.

On my T2 running the same firmware version 19.3, cat proc/stb/vmpeg/0/framerate returns "23976" and I observe no repeated frames on test content. On the V2 it returns "24000". V2 also appears to be outputting 29.97 as 30.00 and 59.94 as 60.00 which will cause similar issues.

Sorry to be a serial complainer, but I feel this needs to be a top priority fix. The vast majority of my video library is 23.976fps and rendered unwatchable on the V2. Having just one repeated frame every now and then might be acceptable for content where there isn't a lot of motion, but for an action scene, forget about it, it's easily noticeable and impossible to ignore.

Am I correct in understanding that the fact the T2 does not have this issue despite being on the same firmware version, implies that it's a fault of the chipset driver and therefore won't ever be fixed? I don't want to keep hoping it's going to be fixed; I'd rather just be put out of my misery now if you wouldn't mind :lol:

User avatar
peteru
Uber Wizard
Posts: 9730
Joined: Tue Jun 12, 2007 23:06
Location: Sydney, Australia
Contact:

Re: V2 various issues

Post by peteru » Tue Jun 02, 2020 12:24

The problem will be in the drivers that are provided by the chipset manufacturer and ODM. Problems like this can't be fixed from the open source side. If Beyonwiz can work with their ODM, it may be possible to get fixes. How likely is that to happen? I can't tell. I do know that the best time to ask for changes and fixes is as a condition of placing an order with the manufacturer or making a payment. It is very hard to get the ODM to provide any fixes after they've been paid.

If you do want to invest some effort into this, I suggest creating a detailed bug report at https://bitbucket.org/beyonwiz/easy-ui-4/issues . Include repeatable steps and (links to) sample media to be used for testing. That bug will need to be understandable by people whose first language is not English and who most likely do not actually use the products that they work on. That means a bug that can be easily reproduced and evaluated based on some simple rules is better than a bug that has a lot of prose and relies on understanding of many concepts. You should also know that the ODM is unlikely to actually develop and test the drivers with the enigma2 distro that we use, so it is best to analyse the issue and concentrate on issues at the driver level interface. The ODM can install something like 19.3 for testing, so initial reproduction steps with 19.3 are OK. Once you have a good bug report, it will need to be brought to the attention of the right people - starting with WizHQ. Whether this exercise will bear any fruit is unclear, but you can be sure that without a solid bug report, we're just complaining to each other.

"Beauty lies in the hands of the beer holder."
Blog.

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Wed Jun 03, 2020 20:01

Thanks, will do. If nothing comes of it I'll probably go the HTPC route for media playback and use the V2 for free to air stuff.

Seem to have stumbled on a solution to the auto res issue (item 5 in OP). It looks like the driver is applying proc/stb/video/videomode_Nhz every time the video stream changes even when multi refresh rate is turned off. Luckily it can be worked around in VideoMode.py (see solution in OP).
Last edited by sonicblue on Wed Jul 01, 2020 13:31, edited 4 times in total.

User avatar
peteru
Uber Wizard
Posts: 9730
Joined: Tue Jun 12, 2007 23:06
Location: Sydney, Australia
Contact:

Re: V2 various issues

Post by peteru » Thu Jun 04, 2020 02:11

Feel free to create a BitBucket pull request if you have a tested fix.

"Beauty lies in the hands of the beer holder."
Blog.

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Thu Jun 04, 2020 04:57

I need to add some more lines to make it more robust, eg. only write to that value if the path exists and new_rate is 50, 60 or 24. I should probably get the vendor info and only do it if the chipset is 3798MV200 since the issue is nonexistent on the T2.
Last edited by sonicblue on Fri Jun 05, 2020 19:31, edited 2 times in total.

User avatar
peteru
Uber Wizard
Posts: 9730
Joined: Tue Jun 12, 2007 23:06
Location: Sydney, Australia
Contact:

Re: V2 various issues

Post by peteru » Thu Jun 04, 2020 14:29

It's probably better to do a test on the specific machine rather than the SoC:

if getBoxType() == "beyonwizv2":

or

if getMachineBuild() == "beyonwizv2":

Please add a comment with a succinct explanation of why a special case is needed and what are the conditions for removing the workaround later, in case we get driver fixes. It makes code maintenance easier.

"Beauty lies in the hands of the beer holder."
Blog.

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Fri Jun 05, 2020 18:33

Cheers.

An alternative solution could be to use a fixed global mode and map the remote's video mode button to force an automatic refresh rate change (VideoResolution.py), then at the next video stream change automatically revert to the fixed global mode.
Last edited by sonicblue on Tue Jun 16, 2020 19:36, edited 1 time in total.

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Mon Jun 08, 2020 12:18

It seems auto res only works up to 720p, otherwise it falls back to the global fixed res (config_res)

Code: Select all

VideoMode.py
if (700 < video_width <= 720) and video_height <= 480 and video_framerate in (23976, 24000, 29970, 30000, 59940, 60000):
			new_res = "480"
		elif (700 < video_width <= 720) and video_height <= 576 and video_framerate in (25000, 50000):
			new_res = "576"
		elif (video_width == 1280) and video_height <=720:
			new_res = "720"
		else:
			new_res = config_res
I speculate 2 possibilities:

1. This was a deliberate decision by the author of VideoMode.py due to inconsistencies in the values reported by iServiceInformation and /proc/stb/vmpeg/0/xyres.

2. The code may be leftover from when most enigma boxes had a max output res of 1080, which only required detecting up to 720.

User avatar
peteru
Uber Wizard
Posts: 9730
Joined: Tue Jun 12, 2007 23:06
Location: Sydney, Australia
Contact:

Re: V2 various issues

Post by peteru » Mon Jun 08, 2020 14:16

Probably 2.

"Beauty lies in the hands of the beer holder."
Blog.

User avatar
peteru
Uber Wizard
Posts: 9730
Joined: Tue Jun 12, 2007 23:06
Location: Sydney, Australia
Contact:

Re: V2 various issues

Post by peteru » Wed Jun 17, 2020 00:58

I notice you keep editing the original post (kind of like a wiki page), but I'm not sure if anyone is seeing the changes.

It may be a good idea to also make separate posts that highlight the changes you are making.

"Beauty lies in the hands of the beer holder."
Blog.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: V2 various issues

Post by prl » Wed Jun 17, 2020 10:11

peteru wrote:
Wed Jun 17, 2020 00:58
I notice you keep editing the original post (kind of like a wiki page), but I'm not sure if anyone is seeing the changes.
sonicblue: only new posts are flagged as "new" in the forum. Edited posts are not flagged as new.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Wed Jun 17, 2020 18:34

Cheers, I'll reply to the thread if I come across any important stuff.
I'm currently in the process of finalising and testing my patches to VideoMode.py.

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Wed Jul 01, 2020 13:25

Unfortunately it seems that /proc/vfmw/pts_info still doesn't report the correct framerate all the time. However it's still better than the alternatives as it seems to reliably report the correct framerate after approximately 2 seconds of a new video stream.

The current solution I'm implementing is a combination of a bodge and a partial workaround. The bodge component is to force 50hz when the source is DVB, since we know DVB is exclusively 50hz in our region, however this doesn't work when playing back TV recordings or media files as they are not DVB source. My partial workaround for non-DVB sources is to use the previous solution of checking pts_info with a timer after 3 seconds, but only if the initial VideoChangeDetect() reported 30fps, based on an observation that the only time pts_info reports an incorrect value is when the value it reports is 30fps. This still allows the possibility that the user zaps to a recording, or between recordings, and the initial pts_info inside VideoChangeDetect() erroneously reports 30fps, forcing the user to wait up to 3 seconds for the display mode to be corrected.

Another possible solution is to just ignore 30/60fps content altogether, since outputting it at 60hz has a tendency to cause the system to become unresponsive for around 30 seconds (test clips to reproduce it: [1][2]).

Given the lack of a 23.976hz mode, I don't personally see any reason to support auto switching to 24.000hz either.

In my opinion V2 is only viable as a 50hz PVR, therefore I may end up using a solution that simply forces 50hz for all resolutions.

Another option may be to play all content through a PC with Kodi and have MadVR handle all the rendering and mode switching, although I've never used Kodi and imagine we'd still need to switch to the V2 for some functionality.
Last edited by sonicblue on Thu Aug 06, 2020 06:39, edited 6 times in total.

raymondjpg
Guru
Posts: 961
Joined: Sun Jul 25, 2010 09:18

Re: V2 various issues

Post by raymondjpg » Wed Jul 01, 2020 14:00

sonicblue wrote:
Wed Jul 01, 2020 13:25
Another option may be to play all content through a PC with Kodi and have MadVR handle all the rendering and mode switching, although I've never used Kodi and imagine we'd still need to switch to the V2 for some functionality.

I'm not sure what functionality you mean. Kodi isn't equipped to use madVR, but it's easy enough to configure an external player in Kodi that does. That'll handle recordings and other videos, and as far as I know there is no functionality in such a setup that would be better served by a V2.

For live TV the Enigma2 Client plugin works OK with Kodi, but you are restricted to using the inbuilt player. I've never found Kodi to be able to detect the 25 fps necessary for unjerky play, and the fallback framerate option has never seemed to work for me. I can get around it by playing a 25 (or50) fps video with the external player, and madVR set to not revert to previous display mode. Live TV is then unjerky. However, there is no option for chase play with this setup; that is a functionality that you would have to look to the V2 for.
Beyonwiz T2, Beyonwiz U4, IceBox BYO with Hauppauge WinTV-dualHD (x2), Hauppauge WinTV-quadHD

User avatar
MrQuade
Uber Wizard
Posts: 11842
Joined: Sun Jun 24, 2007 13:40
Location: Perth

Re: V2 various issues

Post by MrQuade » Wed Jul 01, 2020 15:26

I dont think that any solution that involves assuming that dvb-t sources are 50Hz is the right way to go.
Logitech Harmony Ultimate+Elite RCs
Beyonwiz T2/3/U4/V2, DP-S1 PVRs
Denon AVR-X3400h, LG OLED65C7T TV
QNAP TS-410 NAS, Centos File Server (Hosted under KVM)
Ubiquiti UniFi Managed LAN/WLAN, Draytek Vigor130/Asus RT-AC86U Internet
Pixel 4,5&6, iPad 3 Mobile Devices

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Wed Jul 01, 2020 18:09

raymondjpg wrote:
Wed Jul 01, 2020 14:00
I'm not sure what functionality you mean.

Day to day stuff like managing auto timers, searching the EPG and timeshifting. Functionality that I presume would be exclusive to enigma2. I read somewhere that Kodi can be set up with MadVR as the renderer though. No idea if it's true or works reliably, but I'll give it a shot.

MrQuade wrote:
Wed Jul 01, 2020 15:26
I dont think that any solution that involves assuming that dvb-t sources are 50Hz is the right way to go.

Of course not, that's why I called it a bodge :)

The only reason I would resort to such a bodge is because I can't find any other alternative.

So far I have not had any false positives using the bodge, which is:

Code: Select all

service = self.session.nav.getCurrentService()
info = service.info()
if (getBoxType() == "beyonwizv2") or (getMachineBuild() == "beyonwizv2"):				
	tData = info.getInfoObject(iServiceInformation.sTransponderData)			
	tuner_type = tData.get("tuner_type", "None")			
	if (tuner_type == "DVB-T") and (video_framerate not in (25000, 50000)):				
		new_rate = "50"

User avatar
peteru
Uber Wizard
Posts: 9730
Joined: Tue Jun 12, 2007 23:06
Location: Sydney, Australia
Contact:

Re: V2 various issues

Post by peteru » Wed Jul 01, 2020 20:15

The "proper" way to establish the appropriate video mode would be to parse the stream data and find out for sure, even before feeding anything to the decoder. Such a change would probably entail quite a lot of work.

"Beauty lies in the hands of the beer holder."
Blog.

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Thu Jul 02, 2020 22:39

A workaround for the aspect ratio issue has been identified (see item 10).
Last edited by sonicblue on Fri Jul 31, 2020 11:06, edited 2 times in total.

captain
Apprentice
Posts: 95
Joined: Thu May 01, 2014 04:57

Re: V2 various issues

Post by captain » Fri Jul 03, 2020 14:20

the beyonwizv2 image use last drivers ? see git https://github.com/oe-alliance/oe-allia ... a-beyonwiz

when you use last drivers and libs and have issue with drivers beyonwiz can report the issue to the driver team and we can help fix some issues

User avatar
MrQuade
Uber Wizard
Posts: 11842
Joined: Sun Jun 24, 2007 13:40
Location: Perth

Re: V2 various issues

Post by MrQuade » Fri Jul 03, 2020 14:54

captain wrote:
Fri Jul 03, 2020 14:20
the beyonwizv2 image use last drivers ? see git https://github.com/oe-alliance/oe-allia ... a-beyonwiz

when you use last drivers and libs and have issue with drivers beyonwiz can report the issue to the driver team and we can help fix some issues
Would be great to check on the ATV firmware too, but we still can't flash OpenATV to the eMMC internal flash.

Is there any update on that?
Logitech Harmony Ultimate+Elite RCs
Beyonwiz T2/3/U4/V2, DP-S1 PVRs
Denon AVR-X3400h, LG OLED65C7T TV
QNAP TS-410 NAS, Centos File Server (Hosted under KVM)
Ubiquiti UniFi Managed LAN/WLAN, Draytek Vigor130/Asus RT-AC86U Internet
Pixel 4,5&6, iPad 3 Mobile Devices

captain
Apprentice
Posts: 95
Joined: Thu May 01, 2014 04:57

Re: V2 various issues

Post by captain » Fri Jul 03, 2020 23:05

you must flash first new recovery system, but looks beyonwiz image use the old

beyonwiz must update the image and you can used both

User avatar
MrQuade
Uber Wizard
Posts: 11842
Joined: Sun Jun 24, 2007 13:40
Location: Perth

Re: V2 various issues

Post by MrQuade » Fri Jul 03, 2020 23:37

captain wrote:
Fri Jul 03, 2020 23:05
you must flash first new recovery system, but looks beyonwiz image use the old

beyonwiz must update the image and you can used both
Mine has the new looking recovery screens, that looks like the new one here:
https://www.opena.tv/octagon-sf8008-4k- ... 020-a.html

I followed that procedure to update with the latest V2 recovery image, but it still won't let me boot.

I flashed one of the latest recovery images from the BeyonwizV2 area here:
http://images.mynonpublic.com/openatv/n ... beyonwizv2
But booting just doesn't go anywhere afterwards and gets stuck.

What am I missing in this procedure?
Logitech Harmony Ultimate+Elite RCs
Beyonwiz T2/3/U4/V2, DP-S1 PVRs
Denon AVR-X3400h, LG OLED65C7T TV
QNAP TS-410 NAS, Centos File Server (Hosted under KVM)
Ubiquiti UniFi Managed LAN/WLAN, Draytek Vigor130/Asus RT-AC86U Internet
Pixel 4,5&6, iPad 3 Mobile Devices

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Thu Jul 09, 2020 16:10

captain wrote:
Fri Jul 03, 2020 14:20
the beyonwizv2 image use last drivers ? see git https://github.com/oe-alliance/oe-allia ... a-beyonwiz

when you use last drivers and libs and have issue with drivers beyonwiz can report the issue to the driver team and we can help fix some issues

Hi captain. How can we check if we have the latest Hi3798MV200 drivers? Which files can we check?

Also, is it possible to upgrade the driver just by pushing some files to the box via FTP, or does the whole image need to be rebuilt and flashed?

The two most important driver issues affecting the Beyonwiz are (imo):

1. Lack of support for 23.976hz HDMI output.

2. Colours become different after playing 4k content and returning to non-4k content, requiring reboot to restore original colours.

(Although, I don't know which one is the "correct" colour... maybe the post-4k colours are correct? Skin tones look a bit less saturated post-4k, which looks a bit better on my display, but ultimately I have no idea. See item 8 in OP for screenshot comparison).

Thanks
Last edited by sonicblue on Fri Jul 31, 2020 11:07, edited 1 time in total.

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Sat Jul 11, 2020 16:55

New bug found: colour space reverts to RGB after setting HDMI output mode to 2160p (see item 9 in OP).

The reason I took so long to notice this one is because my display is not 4k and I never used the 2160p mode.

It appears to be a driver bug as its proc value is still reporting 444 while the actual signal coming out of the HDMI port is RGB.

Thankfully we can workaround it by cycling the proc value back and forth to refresh it. I will soon be releasing a patch which addresses all of the issues in the OP which have a viable workaround or fix. Then hopefully in future we can get a driver update from Huawei and don't have to use these bodgey workarounds.

As mentioned in item 14, RGB mode is undesirable as it can cause incorrect dynamic range on displays which often assume RGB is "full range" (0-255). If you're lucky your display will have its own picture setting which can manually correct the issue by forcing its interpretation of the signal as limited range (16-235). Perhaps more modern displays are better at automatically detecting the range from the HDMI signal metadata (assuming it's present).

However, I now suspect the RGB output always produces incorrect colour, possibly due to incorrect luma coefficients being used to decode the source YCbCr into RGB. The RGB signal coming out of the HDMI port appears to be identical in colour to what the screenshot captures through the OpenWebif, which is definitely wrong colour (I've captured an RGB test pattern ramp through it and the pixel values are not correct). If the RGB HDMI output is the same (which I suspect it is) then the RGB HDMI mode must be avoided altogether.
Last edited by sonicblue on Fri Jul 31, 2020 11:07, edited 1 time in total.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: V2 various issues

Post by prl » Sat Jul 11, 2020 19:18

Peteru is about to start preparing a build of the next major release from (19.3 to 20.3).

That may have relevant fixes do the A/V device drivers.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

User avatar
MrQuade
Uber Wizard
Posts: 11842
Joined: Sun Jun 24, 2007 13:40
Location: Perth

Re: V2 various issues

Post by MrQuade » Tue Jul 14, 2020 23:31

The OpenATV image is now working again if you want to try that out :)

See my post here.
Logitech Harmony Ultimate+Elite RCs
Beyonwiz T2/3/U4/V2, DP-S1 PVRs
Denon AVR-X3400h, LG OLED65C7T TV
QNAP TS-410 NAS, Centos File Server (Hosted under KVM)
Ubiquiti UniFi Managed LAN/WLAN, Draytek Vigor130/Asus RT-AC86U Internet
Pixel 4,5&6, iPad 3 Mobile Devices

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: V2 various issues

Post by prl » Wed Jul 15, 2020 09:54

I've currently got it running in the onboard flash, and I'm trying to see whether it will flash to microSD and run from there.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

User avatar
MrQuade
Uber Wizard
Posts: 11842
Joined: Sun Jun 24, 2007 13:40
Location: Perth

Re: V2 various issues

Post by MrQuade » Wed Jul 15, 2020 11:18

prl wrote:
Wed Jul 15, 2020 09:54
I've currently got it running in the onboard flash, and I'm trying to see whether it will flash to microSD and run from there.
It looks to me like the 6.5 image isn't quite ready for prime time in terms of plugin support.

I first attempted to simply restore my old settings and plugins, but received multiple errors in the plugin browser, particularly relating to Netflix and Kodi.

I thought that maybe some old cruft in my settings was a potential issue, so reflashed back to stock. Same issues with Netflix with a clean install, so I didn't explore any further.

Lighter plugins like EPGRefresh and remotechannelstreamconverter worked fine though.

Anyway. 6.5 probably not ready to be a daily driver yet, but it should still be a good test bed for the newer drivers and video modes for sonicblue.
Logitech Harmony Ultimate+Elite RCs
Beyonwiz T2/3/U4/V2, DP-S1 PVRs
Denon AVR-X3400h, LG OLED65C7T TV
QNAP TS-410 NAS, Centos File Server (Hosted under KVM)
Ubiquiti UniFi Managed LAN/WLAN, Draytek Vigor130/Asus RT-AC86U Internet
Pixel 4,5&6, iPad 3 Mobile Devices

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: V2 various issues

Post by prl » Wed Jul 15, 2020 11:21

Flash Online in 6.5.20200714 crashes because a helper python script that's written and run by Flash_online.py is not Python3 compatible.

After the crash the ATV UI wedges, and has to be killed off and restarted with "killall -KILL enigma2".

I've told Captain about the problem via another channel, too.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: V2 various issues

Post by prl » Wed Jul 15, 2020 11:23

MrQuade wrote:
Wed Jul 15, 2020 11:18
prl wrote:
Wed Jul 15, 2020 09:54
I've currently got it running in the onboard flash, and I'm trying to see whether it will flash to microSD and run from there.
It looks to me like the 6.5 image isn't quite ready for prime time in terms of plugin support.

IanSav has been putting out some spot fires in the 6.5 images, but some of them probably haven't filtered through yet. Kodi is a known problem (or at least there is a known problem with Kodi).
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: V2 various issues

Post by IanSav » Wed Jul 15, 2020 13:45

Hi,

OpenATV 6.5 is definitely not for production use. The OpenATV team want as many developers and testers as possible to run and test it to find all the issues. Efforts to convert the plugins has only just begun.

Kodi is more an issue on OpenPLi. I suspect that they may have different source code or else have some differences in their build that make it less stable on that platform. I believe that Kodi should be pretty stable on OpenATV and OpenViX.

Captain has asked for more of my assistance in resolving issues with OpenATV 6.5. I am waiting for some coding standards information before jumping in too heavily. I am still refactoring core parts of Enigma2 for all the images and Captain has requested that I make all those changes and optimisations to OpenATV ASAP. That work is currently progressing.

My revised skin processor and centralised screen path code is now implemented on all the main images. That joins the new Directories, VirtualKeyBoard and NumericalTextInput that was previously refactored and made common among the images. The new Setup code is being tested on OpenViX and will soon be rolled out on the other main images. I am also hoping that Prl's new help engine will also soon roll out to all the main images. I have no idea what Beyonwiz is doing about all the new code. Beyonwiz is now quite far behind all the other images.

Regards,
Ian.

User avatar
MrQuade
Uber Wizard
Posts: 11842
Joined: Sun Jun 24, 2007 13:40
Location: Perth

Re: V2 various issues

Post by MrQuade » Wed Jul 15, 2020 14:12

IanSav wrote:
Wed Jul 15, 2020 13:45
Kodi is more an issue on OpenPLi. I suspect that they may have different source code or else have some differences in their build that make it less stable on that platform. I believe that Kodi should be pretty stable on OpenATV and OpenViX.
Right now, it seems quite broken, if only that there seems to be no way to actually launch it :).
IanSav wrote:
Wed Jul 15, 2020 13:45
I have no idea what Beyonwiz is doing about all the new code. Beyonwiz is now quite far behind all the other images.
Well, the process of building a 20.x firmware is underway just now, so time will tell :)
Hopefully a major upstream merge is in the works :)
Logitech Harmony Ultimate+Elite RCs
Beyonwiz T2/3/U4/V2, DP-S1 PVRs
Denon AVR-X3400h, LG OLED65C7T TV
QNAP TS-410 NAS, Centos File Server (Hosted under KVM)
Ubiquiti UniFi Managed LAN/WLAN, Draytek Vigor130/Asus RT-AC86U Internet
Pixel 4,5&6, iPad 3 Mobile Devices

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Tue Jul 21, 2020 07:33

Seem to have a bodge workaround for the sharpness bug (item 12 in OP). Previously I mentioned that opening and closing the graphical EPG with picture in graphics enabled would reset the bug, but only until the next time the user zaps to another SD stream, at which point the bug is reinstantiated. A workaround is to use the same trick: open a GUI dialog with a full frame picture in graphics and then immediately close it, performed n seconds after the beginning of every video stream.

Another approach I tried was stopping and starting the current service, which also works, albeit not reliably enough as there were some edge cases which I couldn't solve, and is annoying for the user as it causes zaps to be longer and ungraceful.

edit: new bug found: sharpness control becomes nonfunctional during video content which is being letterboxed or pillarboxed by the V2 (i.e proc/stb/video/policy = letterbox and content is a non-16:9 format, eg. 1920x800 2.4:1 or 720x576 4:3 non-anamorphic). I suspect this might be intentional, and there doesn't seem to be any workaround.
Last edited by sonicblue on Sat Aug 01, 2020 23:49, edited 2 times in total.

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Fri Jul 31, 2020 00:34

New bug found: video enhancement auto flesh setting of 0 appears to be mapping to an enabled value in the driver (see item 7 in OP). Easily fixed by disabling the setting in VideoMode.py, and this will be incorporated into my upcoming patch.

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Thu Aug 06, 2020 02:44

sonicblue wrote:
Fri May 22, 2020 19:55
4. Frame rate randomly begins to stutter

When playing live TV, the frame rate occasionally becomes stuttery and requires re-initialising the video stream to correct it, such as by zapping to another channel and back again, or pausing and unpausing into the timeshift buffer, or opening and closing the media library. I have noticed that VideoMode.py: VideoChanged() coincides with the issue. i.e watching a video stream and then for no apparent reason VideoMode.py: VideoChanged() occurs, and the frame rate becomes stuttery.

Finally got to the bottom of this one. I am able to reproduce the issue by artificially inducing some impulse noise signal interference while tuned to 9Gem, such as turning a lamp on and off repeatedly. The problem appears to be the decoder doesn't properly recover from the signal interference and the rendering frame rate becomes stuttery. The success rate of this happening seems to be around 50%, and further interference has a similar chance of remedying the issue.

Thankfully we do have events which occur when DVB interference is encountered, eg. evTunedIn, which we can use to reset the frame rate via the proc command. My current strategy is to only start monitoring evTunedIn <delay> seconds after tuning to a DVB service, in order to minimise the usage of this bodge.

After extensive testing it seems to require some specific values to work reliably. Appear to have success by setting the fps down to quite a low value of 5fps, sleeping for 100ms, then increasing it back to the previous frame rate, i.e 25fps. If I use values such as 20fps or don't sleep long enough in between, the reliability becomes <100%. A few seconds of delay after the evStart event seems to help too.

Also investigated these values in proc/vfmw/info (see proc/vfmw/help for usage)

Code: Select all

set bitstream control period    0x501     period (ms)
set frame control period        0x502     period (ms)
set rcv/rls img control period  0x503     period (ms)
set no stream report period     0x504     period (ms)
I tried some different values for frame control period without effect, but I'm uneasy about mucking with these settings. For all I know they might place an extra workload on the GPU and increase idle temps (which can be viewed in proc/hisi/msp/pm_*). For now I'd rather just reset the decoder fps as it appears to be safe, and doesn't appear to inconvenience the user in any way.

I will need to do more testing, for example checking whether resetting the decoder fps interferes with active recordings, or whether it causes any other side effects.

edit: it seems it will not be possible to workaround the issue with 100% reliability, as it is possible for the amount of signal interference to be so slight that it doesn't trigger an evTunedIn event, nor any other event, and yet still causes the frame rate stutter. I am still considering whether to include this fix in my patch, as signal interference is quite common, so the code has to be air tight and impervious to all kinds of random patterns and timings of interference. eg. if the user zaps multiple times during multiple bouts of signal interference, the code cannot get confused about what fps it should be setting, otherwise the wrong fps could be set. For example, I'm relying on evEnd as a thread latch, as it seems to be the only reliable way to know when the user has zapped. Otherwise there is the possibility of setting the decoder fps just after the user has zapped. Our DVB is all 25fps so this wouldn't actually be a disaster if it occurred, and I'm limiting this workaround to DVB HD channels only (as I've never observed it elsewhere) but still, anything less than air tight code will not be acceptable. Even with perfect code, there will still be one line of execution between checking the latch state and setting the decoder fps during which a zap event could occur.

sonicblue
Master
Posts: 247
Joined: Wed Oct 25, 2017 14:30

Re: V2 various issues

Post by sonicblue » Thu Aug 13, 2020 04:53

sonicblue wrote:
Fri May 22, 2020 19:55
6. When display mode is set to 24hz, 23.976fps media files are output at 24.000hz

For what it's worth, I tried using proc/msp/vdec_ctrl to nudge the frame rate by 1fps every 41.6 seconds, without success. I believe the issue is that proc/msp/vdec_ctrl doesn't speed up the decoding frame rate, only the rendering frame rate. Also tried to use the setFastForward function in decoder.cpp, also without success.

Post Reply

Return to “Bug Reporting and Feature Requests”