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.
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.
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.
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:
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
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.
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.