• 1
  • 48
  • 49
  • 50(current)
  • 51
  • 52
  • 168
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)
Every once in a while, I get a tiny droupout (gap) in the audio. Is this likely from limiting the hdmi_clock AND using Adjust PLL together? In case it matters, I don't use the Adjust Display Refresh Rate setting because that causes a lot of resyncing to occur with my AVR and projector.
Experience: It's what you get when you were expecting something else.
(2015-08-17, 12:51)popcornmix Wrote:
(2015-08-17, 11:48)Gregoire Wrote: Since last update 816 audio volume goes up and down without intervention in Livetv/ PVR

Are you saying this is new to 816 (i.e. 815 was fine)?
Based on the list of changes that seems hard to imagine.
Do you have a non-zero amplification (set on OSD/audio settings)?

I have no idea what you just said. But. The problem remained with the volume going up and down and sometimes a stream starts with white noise and loud crackles. Normally I have an idea of where the problem could stem from but I have no clue now.
(2015-08-18, 05:22)afremont Wrote: Every once in a while, I get a tiny droupout (gap) in the audio. Is this likely from limiting the hdmi_clock AND using Adjust PLL together? In case it matters, I don't use the Adjust Display Refresh Rate setting because that causes a lot of resyncing to occur with my AVR and projector.

Try enabling adjust display refresh rate and see if that avoids the issue.
The "sync playback" setting may be trying to adjust 24Hz to 25Hz (e.g. for a 50Hz display) which needs resampling to be enabled.
Although I suspect you may be better off with "resample audio" if adjust PLL doesn't work well in your setup.
(2015-08-18, 10:50)Gregoire Wrote: I have no idea what you just said. But. The problem remained with the volume going up and down and sometimes a stream starts with white noise and loud crackles. Normally I have an idea of where the problem could stem from but I have no clue now.

Video_playback#OSD_audio_and_subtitle_settings (wiki)
(2015-08-18, 12:11)popcornmix Wrote:
(2015-08-18, 10:50)Gregoire Wrote: I have no idea what you just said. But. The problem remained with the volume going up and down and sometimes a stream starts with white noise and loud crackles. Normally I have an idea of where the problem could stem from but I have no clue now.

Video_playback#OSD_audio_and_subtitle_settings (wiki)

I see. Yes, I had it set on 30. Will change it back to 0, see what happens.

EDIT: It worked. Underwhelmed because I could have known...
Small niggle with 0817, bcmstat.sh doesn't seem to work:

rpi:~ # bcmstat.sh
-sh: bcmstat.sh: Permission denied

/usr/bin/bcmstat.sh is zero bytes.
(2015-08-18, 15:47)zaphod24 Wrote: Small niggle with 0817, bcmstat.sh doesn't seem to work:

rpi:~ # bcmstat.sh
-sh: bcmstat.sh: Permission denied

/usr/bin/bcmstat.sh is zero bytes.

working fine here on 0817, it seems the file got corrupted (0 bytes, permission..)

EDIT: ups, I have my own copy in /storage, so it is realy not working
Yep, sorry about that - it's 0 bytes in both the Pi1 and Pi2 builds, there must have been a temporary glitch with github.com during the build. Should be OK tonight.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2015-08-03, 19:08)wchick132 Wrote: The following is link to the same TV episode encoded myself, both x265/HEVC video and English subtitle file.
https://drive.google.com/folderview?id=0...XpmeEsxcG8

I finally got some time to look into this. It was a firmware issue. Should be a fix in tonight's build. Thanks for the sample.
(2015-08-18, 20:07)popcornmix Wrote:
(2015-08-03, 19:08)wchick132 Wrote: The following is link to the same TV episode encoded myself, both x265/HEVC video and English subtitle file.
https://drive.google.com/folderview?id=0...XpmeEsxcG8

I finally got some time to look into this. It was a firmware issue. Should be a fix in tonight's build. Thanks for the sample.

Thanks so much.
(2015-08-18, 12:10)popcornmix Wrote:
(2015-08-18, 05:22)afremont Wrote: Every once in a while, I get a tiny droupout (gap) in the audio. Is this likely from limiting the hdmi_clock AND using Adjust PLL together? In case it matters, I don't use the Adjust Display Refresh Rate setting because that causes a lot of resyncing to occur with my AVR and projector.

Try enabling adjust display refresh rate and see if that avoids the issue.
The "sync playback" setting may be trying to adjust 24Hz to 25Hz (e.g. for a 50Hz display) which needs resampling to be enabled.
Although I suspect you may be better off with "resample audio" if adjust PLL doesn't work well in your setup.

Well, this has all been about live TV and recorded TV in the US, so the refresh rate should be pretty consistent. I switched back to Resample Audio and I don't notice any glitches of any kind. Is there any "penalty" for using that? I thought it might cause the passthrough to stop happening, but my AVR still shows DD 2.0 as the input which is what it started off as for that channel. I still have the hdmi_clock_change_limit=40 thingy in there.

I can't really live with the Adjust Refresh Rate setting. It causes black screens while the AVR and projector try to figure out what the heck is going on. So far, using hdmi_clock_change_limit combined with Resample Audio seems to provide the best experience. Without the clock change limit, then Adjust PLL is probably best except for the 2-3 second audio startup delay every time you change channels or unpause.

I haven't changed the deinterlacer from Auto, but I swear this stuff looks better than it did several releases back. I watch a lot SD quality TV/recordings and it looks great to me. I'm pretty picky about that kind of thing too. I'll have to try some 1080i video and see if I can tell anything about that. The HD stuff that gets recorded is 720p so I don't think deinterlacing would be in effect then, right?
Experience: It's what you get when you were expecting something else.
(2015-08-18, 21:16)afremont Wrote: I haven't changed the deinterlacer from Auto, but I swear this stuff looks better than it did several releases back. I watch a lot SD quality TV/recordings and it looks great to me. I'm pretty picky about that kind of thing too. I'll have to try some 1080i video and see if I can tell anything about that. The HD stuff that gets recorded is 720p so I don't think deinterlacing would be in effect then, right?

There was a tweak to the MMAL Advanced algorithm which cleaned it up quite a lot a little while ago, improving SD deinterlacing a lot. If you overclock a little you can also use MMAL Advanced on 1080i stuff with the latest builds instead of being limited to MMAL Bob.
(2015-08-18, 23:44)noggin Wrote:
(2015-08-18, 21:16)afremont Wrote: I haven't changed the deinterlacer from Auto, but I swear this stuff looks better than it did several releases back. I watch a lot SD quality TV/recordings and it looks great to me. I'm pretty picky about that kind of thing too. I'll have to try some 1080i video and see if I can tell anything about that. The HD stuff that gets recorded is 720p so I don't think deinterlacing would be in effect then, right?

There was a tweak to the MMAL Advanced algorithm which cleaned it up quite a lot a little while ago, improving SD deinterlacing a lot. If you overclock a little you can also use MMAL Advanced on 1080i stuff with the latest builds instead of being limited to MMAL Bob.

How much do I have to overclock? I don't currently do that and my CPU runs a little over 51C as it is. Here is some sample output of bcmstat.sh watching an SD program:
Code:
Config: v0.2.6, args "", priority lowest (+19)
     CPU: 4 x ARMv7 cores available, using ondemand governor
  Memory: 1008MB (split 752MB ARM, 256MB GPU)
HW Block: |   ARM   |  Core  |  H264  |    SDRAM    |
Min Freq: |  600MHz | 250MHz |   0MHz |    450MHz   |
Max Freq: |  900MHz | 300MHz | 300MHz |    450MHz   |
Voltages: |         0, 1.3125V        |  0, 1.2000V |
   Other: temp_limit=85
Firmware: Aug 15 2015 17:55:46, version b22c2fd27dc8091883457064d8ebc3ac7c995309 (clean) (release)
  Codecs: H264 WVC1 MPG2 VP8 VORBIS MJPG
  Booted: Tue Aug 18 12:34:10 2015

Time         ARM    Core    H264 Core Temp (Max)  IRQ/s     RX B/s     TX B/s
======== ======= ======= ======= =============== ====== ========== ==========
16:48:26  900Mhz  250Mhz  250Mhz 50.84C (50.84C)  1,086      1,029      8,507
16:48:28  900Mhz  250Mhz  250Mhz 51.38C (51.38C)  1,231    227,838      8,947
16:48:30  600Mhz  250Mhz  250Mhz 50.31C (51.38C)  1,218    213,734      8,028
16:48:32  600Mhz  250Mhz  250Mhz 49.77C (51.38C)  1,307    319,033      9,562
16:48:34  600Mhz  250Mhz  250Mhz 50.84C (51.38C)  1,303    316,485      9,639^C
Peak Values: IRQ: 1307, RX: 319033, TX: 9639
Experience: It's what you get when you were expecting something else.
Strange bug with #817. When Live TV (SD Freeview) is playing, if i switch to the EPG after a short while I hear a cut out in the audio and switching back to Full Screen shows the picture has frozen. It tends to Buffer shortly after but the picture doesn't resume.

However, with Debug logging enabled this doesn't happen and Live TV continues to play normally if I switch to the EPG, which makes it rather hard to gather a useful log for you!

I updated from #809 and didn't run into this issue with that and I'm sure I wasn't always testing with Debug logging enabled due to the intrusive overlay.

I have actually set <loglevel hide="false">1</loglevel> in advancedsettings.xml, which in theory should enable debug logging all the time with no overlay but I'm not sure whether that's working or what happens when I toggle Debug logging ON/OFF in OE, as it shows Off normally, despite that entry.

I've uploaded the current log (350MB compresed down to 24MB) anyway, in case it shows anything useful.
https://drive.google.com/file/d/0B1fDI89...sp=sharing
Why are the 16.x builds so much slower to boot? It's like they are waiting for something, nothing wrong just booting slow.

Both on P1 and 2.
  • 1
  • 48
  • 49
  • 50(current)
  • 51
  • 52
  • 168

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)10