OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 1 - Printable Version +- Kodi Community Forum (https://forum.kodi.tv) +-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33) +--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111) +---- Forum: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166) +---- Thread: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 1 (/showthread.php?tid=211501) Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - afremont - 2015-03-19 (2015-03-19, 14:42)zaphod24 Wrote: Thanks for the 0319x debug build. Of course it has been perfect and not crashed, so I guess the issue with the EPG is fixed So far so good on this end too. I haven't played with it much, but it seems to be working ok. Looking forward to the real 319 build. I just put it through a few hoops and it's looks pretty good. Recordings seem to start faster than before. EDIT: I thought I should add that it's been running for hours without issue. I'll put on a recording and let it run while I go to lunch. RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Heiko123 - 2015-03-19 (2015-03-19, 04:53)Milhouse Wrote: @zaphod24/@afremont: There's a debug-enabled RPi2 build with menakite's patch here: #0319x (not bothering with an RPi build as you're both RPi2 users) - please upload your crash logs if it continues to crash, thanks. I've tested the #0318 for RPi, but the same problem, crash after epg-load. Is it possibly to get a #0319-alpha-testbuild for rpi ? RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Milhouse - 2015-03-19 That's great, thanks both. RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Milhouse - 2015-03-19 (2015-03-19, 20:28)Heiko123 Wrote: I've tested the #0318 for RPi, but the same problem, crash after epg-load. There's a debug build, #0319x, or wait for tonight's regular build. RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Milhouse - 2015-03-20 New OpenELEC Isengard build #0319: RPi / RPi2 (Supercedes previous build) Code: # uname -a Based on tip of OpenELEC master (788bd7a7, changelog) and tip of XBMC master (79107ec6, changelog) with the following modifications:
AW: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Heiko123 - 2015-03-20 Thanks, all is fine. I dont get a epg crash. RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - afremont - 2015-03-20 Just a heads up: After about an hour, I'm noticing the audio video sync getting off enough that my wife even notices. I'm fairly sure we get the same thing with OE 5.0.6 too. This is with TV recordings (MPEG2). If I completely stop and resume it, it's ok again. She pauses and skips back and forth a lot, but I don't know if that has anything to do with it. Tonight, I'll check if it shows when pressing O and looking at the codec info. I use OMXPlayer. Audio Offset is most definitely set to 0.000 this time, for sure. Seems to be generating a lot of these during playback: Code: 04:50:03 72266.812500 T:1583346752 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer The snippet is from letting it play for a minute and then stopping the recording playback. Looks like it is continually generating the "didn't consume full packet" while playing back, then skipping cause it to spit out teh CRenderManager::WaitForBuffer line followed by the packet consumption errors. These are related to the subtitle stream being opened (stream 0). I believe that OE 5.0.6 simply refuses to open the stream at all. There's something fishy about WMC recorded TV subtitle streams. Maybe this is problem with OMXPlayer? I'll try MMAL, but in the past it just didn't like the recorded TV streams, might be from the TV signal quality. Maybe all of it is related to signal quality. Here's the beginning of the playback messages: Code: 04:43:26 71869.726562 T:1968910336 NOTICE: DVDPlayer: Opening: smb://USERNAME:PASSWORD@I7-PC/Users/Public/Recorded TV/Thriller_KUBEDT4_2015_03_19_03_00_01.wtv FYI, it's been up since around 9:00am yesterday with no crashes. RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - afremont - 2015-03-20 Maybe the OMXPlayer audio video sync issue is related to this: http://stackoverflow.com/questions/21443165/omxplayer-audio-out-of-sync http://stackoverflow.com/questions/21399550/videoview-does-not-play-audio-in-video-properly/21422270#21422270 What are the command line arguments to ffmpeg and OMXPlayer? RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - popcornmix - 2015-03-20 (2015-03-20, 12:05)afremont Wrote: Just a heads up: I would be useful to confirm that nightly and 5.0.6 behave the same (I suspect they will). Also use to describe the behaviour with omxplayer acceleration disabled. Try to identify exactly what causes the issue. Do you ever see audio/video glitches (e.g. caused by a bad signal) in these files? Does out-of-sync typically follow these? Does pause/unpause or seeking make it better/worse? Use the OSD audio settings to adjust sync to correct it, and report how much correction is required If you can provide a sample file with clear instructions of how to see the problem (e.g. play and it starts in sync, but it is +300ms out of sync at 1m30, or seek forwards twice and it will be -200ms out of sync). Upload file (e.g. to dropbox or google drive) and I'll look into it. RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - wrxtasy - 2015-03-20 I can confirm that Live mpeg2 TV exhibits the same audio video sync problem in Openelec 5.0.6. I left the World cup cricket playing all day and when a News service started, minor audio / video lip sync problems were noticable. This would have been after 5 or 6 hours of continuous play. No user intervention with Kodi all that time. OMXPlayer Acceleration enabled No Audio or Video glitches Signal Quality good. Will try the ms correction next time I see it. RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - afremont - 2015-03-20 I can say this much with reasonable confidence. Completely stopping playback and resuming it seems to fix it. It seems to creep in over time. I'm playing the recording that did it last night. I'll let it go for a while and report back. Right now, the codec report shows ad:3.13x and a/v:-4.2xx. The a/v numbers shuffle around by + or - 100mS and the ad numbers by about + or - 10mS. The video stream shows a vq of 54% + or - 1% and the dc:omx-mpeg2,Mb/s:1.75 to 2.20. That seems like a fairly low quality stream, but that's what they transmit on that sub channel. aq stays pretty much locked at 99% Kb/s:187 to 188. I have verified that the codec is enabled and OMXPlayer is hardware enabled during this test. I played the video completely through without skipping around, just pausing a couple of times so that it didn't end before I could check the sync near the end of video. It remained reasonably close. This was the same video my wife played last night that got at least 500mS out of sync. I'm now going to try it with a bunch of skipping around. Here is a screen shot with the codec info showing: https://www.dropbox.com/s/6x53oauc2todpuz/screenshot000.png?dl=0 Does that look reasonable for a Pi2? OT: I'm not sure that I really like (trust) Dropbox yet. It seems kind of intrusive and heavy handed on resources. I'll reserve judgment until I can check some things. 48 threads and 13 IP connections without even having their "folder" open from their process that runs all the time. And I thought Google was suspicious. EDIT: There, all cleaned up now. No more junk running on my pc. RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - afremont - 2015-03-20 I can't duplicate the problem. I tried skipping back and forth, pausing and skipping while paused. Nothing seems to put it as far off as it got last night. If I can find anything that will consistently duplicate the problem, I'll bring it up again. I can say that it's almost always a tiny amount off. Just perceptible to me. It seems to move back and forth just a little, going in and out of sync by maybe 100mS or probably less. I suspect most people can't see it, but my eyes resolve many images per second compared to normal people. I can always see the rainbows artifacts in DLP technology. It took me weeks to "learn" to ignore it on our projector. Dimming the image helps. It's an Optoma HD25e I'm positive that the receiver and projector aren't to blame since I don't see AV sync issues on any other programming. RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - zaphod24 - 2015-03-20 I have a similar dilemma. Kodi is connect to MythTV and my TV tuner is an HD Homerun Prime with Charter as my cable provider, all content is MPEG2. There are a small number of local channels that have HD on the main channel and then SD on several sub-channels.An example SD channel is MeTV which shows old programs like Andy Griffith, I Love Lucy and Star Trek TOS. What I've noticed is that with OMXPlayer disabled, those channels have a lot of stutter. This seems very strange because all of the HD content is spot-on with OMXPlayer disabled and you'd think HD content would be much more demanding and prone to issues. Instead it is SD that has a problem. If I enable OMXPlayer then both the HD and the SD channels look great. Unfortunately OMXPlayer also crashes sometimes with errors like this in the logs: COMXAudioCodecOMX::GetData Unexpected change of size (12288->36864) It would not surprise me if the MPEG2 streams from Charter have errors in them from time to time due to signal interference. OMXPlayer appears to be much more sensitive to those issues and crashes. Perhaps that is why it is no longer enabled by default in these builds? Has anyone else seen those issues? If DVDPlayer was somehow corrected to work well with the SD content, all would be well. RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - popcornmix - 2015-03-20 (2015-03-20, 16:29)zaphod24 Wrote: What I've noticed is that with OMXPlayer disabled, those channels have a lot of stutter. This seems very strange because all of the HD content is spot-on with OMXPlayer disabled and you'd think HD content would be much more demanding and prone to issues. Instead it is SD that has a problem.The double rate deinterlacers tend to stress dvdplayer more than omxplayer. Try disabling deinterlace, or using the "half" versions if you have stutters with dvdplayer. Provide a sample file with stutters and I'll look into it. Quote:If I enable OMXPlayer then both the HD and the SD channels look great. Unfortunately OMXPlayer also crashes sometimes with errors like this in the logs:Seems the audio codec is changing frame size. It's easy to solve, but I need a debug enabled log (or a sample file). Quote:Has anyone else seen those issues? If DVDPlayer was somehow corrected to work well with the SD content, all would be well.Get me a sample file that plays badly with dvdplayer... RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - afremont - 2015-03-20 I had a lot of that stuttering, then speed variations as it resynced before, so I just made a practice of not using DVDPlayer. I'm trying DVDPlayer right now and it looks pretty decent so far. Watching MeTV as well with it's horrible bitrate for video. Here is a screenshot with codec info showing: https://www.dropbox.com/s/fr42j7tpm5h3gn5/screenshot001.png?dl=0 Looks like it skips a frame about every 10 (maybe 9.9ish) seconds. The drop:1 and pc:1 are from the beginning. As long as DVDPlayer can keep up the good work, I'm satisfied to use it instead of OMXPlayer. I'll have to give it some time and see how it goes. It seems to maintain better A/V sync than OMXPlayer at all times. I don't notice the sliding around. It might be off by a tiny amount, but it's completely acceptable. I see the codec info seems to show the a/v going from 0 to -0.040 at the max. It takes about 1 second for a cycle of that to happen. It's updating so fast that's it's really hard to tell. I'd have to make a movie of the screen to actually see what it's doing. At any rate, it looks pretty good. I'll try sticking with DVDPlayer instead. Skipping a frame every 10 seconds isn't noticeable. Is the frame skip due to syncing to the refresh rate of the display (projector Optoma HD25e)? As in a phase type mismatch? I ask because the skip seems to occur at precise intervals. |