Guest - Testers are needed for the reworked CDateTime core component. See... https://forum.kodi.tv/showthread.php?tid=378981 (September 29) x
  • 1
  • 70
  • 71
  • 72(current)
  • 73
  • 74
  • 168
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)
(2015-09-03, 20:07)popcornmix Wrote:
(2015-09-03, 18:54)polo_joe Wrote: When tuning to 1080i50 tvchannel I get the following errors in tvheadend log.
I think this could cause my artefacts:

http://pastebin.com/5JMMbf73

You said you get artefacts when advanced deinterlace is enabled.
You said you get artefacts from recordings.

So concentrate on the recordings.
Do the artefacts in recording appear only when advanced deinterlace is enabled?
If so then tvheadend is not to blame.
If a recording always has artefacts regardless of deinterlace settings then the problem is in the file (and is likely due to tvheader/tuner backend).

On tvheadend forum I was told, I could suffer from an usb bandwidth issue, as my artefacts and continuity errors only appear when watching high bandwidth hd channels.
Is there a way to check this out or is the rpi 2 bandwidth too low for watching hd livetv when backend on same pi?
@Hitcher: I've created a thread for x86 OpenELEC/Kodi 16 test builds here. Probably worth continuing the discussion there, but I've confirmed the keyboard is working in an Nvidia_Legacy build #0828, but is not working in #0902... need to consider what happened between those two builds...
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-09-10, 11:28)polo_joe Wrote:
(2015-09-03, 20:07)popcornmix Wrote:
(2015-09-03, 18:54)polo_joe Wrote: When tuning to 1080i50 tvchannel I get the following errors in tvheadend log.
I think this could cause my artefacts:

http://pastebin.com/5JMMbf73

You said you get artefacts when advanced deinterlace is enabled.
You said you get artefacts from recordings.

So concentrate on the recordings.
Do the artefacts in recording appear only when advanced deinterlace is enabled?
If so then tvheadend is not to blame.
If a recording always has artefacts regardless of deinterlace settings then the problem is in the file (and is likely due to tvheader/tuner backend).

On tvheadend forum I was told, I could suffer from an usb bandwidth issue, as my artefacts and continuity errors only appear when watching high bandwidth hd channels.
Is there a way to check this out or is the rpi 2 bandwidth too low for watching hd livetv when backend on same pi?
I used to get artefacts quite often when watching live tv or recordings with tvheadend, sometimes almost the whole picture would turn green for a second. I switched to VDR because of timeshift problems, and since then I have not noticed any artefacts with live tv.
Leopold's Repository: Home of LibreELEC Dev Updater ...
Quote:I used to get artefacts quite often when watching live tv or recordings with tvheadend, sometimes almost the whole picture would turn green for a second. I switched to VDR because of timeshift problems, and since then I have not noticed any artefacts with live tv.

I already tried vdr, but I had the same artefacts on the same channel. All others were ok.
When I was using the same tvheadend config on my x86_64 machine I had no issues so I thought it should be a pi problem.
(2015-09-10, 13:19)polo_joe Wrote:
Quote:I used to get artefacts quite often when watching live tv or recordings with tvheadend, sometimes almost the whole picture would turn green for a second. I switched to VDR because of timeshift problems, and since then I have not noticed any artefacts with live tv.

I already tried vdr, but I had the same artefacts on the same channel. All others were ok.
When I was using the same tvheadend config on my x86_64 machine I had no issues so I thought it should be a pi problem.

did you try http://tvheadend.org/issues/3068#note-3 ?
(2015-09-10, 14:20)L-S-D Wrote:
(2015-09-10, 13:19)polo_joe Wrote:
Quote:I used to get artefacts quite often when watching live tv or recordings with tvheadend, sometimes almost the whole picture would turn green for a second. I switched to VDR because of timeshift problems, and since then I have not noticed any artefacts with live tv.

I already tried vdr, but I had the same artefacts on the same channel. All others were ok.
When I was using the same tvheadend config on my x86_64 machine I had no issues so I thought it should be a pi problem.

did you try http://tvheadend.org/issues/3068#note-3 ?

Yes I tried that, I opened the ticket.
(2015-09-10, 13:19)polo_joe Wrote: When I was using the same tvheadend config on my x86_64 machine I had no issues so I thought it should be a pi problem.

Also to try: Add dwc_otg.fiq_fsm_mask=0xF in cmdline.txt to enable a USB hack (see this patch for more info).
Katastrophentourist
Consistent problem with music scan of specific folder.
All my music folders are named like this: \band\year - album name
Odd band name, I know http://www.amazon.com/200-Km-Wrong-Lane-...s_dp_dpt_1

I have even deleted and recreated the folder and rewrote all MP3 tags within the folder, it is because the folder name is so weird?
\\FILE-SERVER\Music\t.A.T.u\2001 - 200 Po Vstrechnoy
\\FILE-SERVER\Music\t.A.T.u\2002 - 200 kmh in the Wrong Lane


http://pastebin.com/raw.php?i=huQ5QgYZ
@J_E_F_F: Which was the last working build?
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.
honestly, I believe it has been a problem since day 1 for me, which was early July of this year.
I just cleaned the music DB, and it no longer shows in the log, but it does hang on the t.a.t.u folder for about 15 seconds and then stops scanning. This is a full log after a reboot and scan. Not listed here this time. http://sprunge.us/gTfZ
(2015-09-10, 16:07)J_E_F_F Wrote: honestly, I believe it has been a problem since day 1 for me, which was early July of this year.
I just cleaned the music DB, and it no longer shows in the log, but it does hang on the t.a.t.u folder for about 15 seconds and then stops scanning. This is a full log after a reboot and scan. Not listed here this time. http://sprunge.us/gTfZ

Code:
18:00:06   6.352966 T:1966755840  NOTICE: Disabled debug logging due to GUI setting. Level 0.

Debug logging was not enabled.
Sorry about that, here it is with debugging
http://sprunge.us/chDC

I don't see anything crazy there with t.a.t.u. Upon boot it goes through the database twice, slowly the first time and goes right through t.a.t.u, then it runs through very quickly the 2nd time. It runs A-Z and then back tracks and hangs on t.a.t.u for almost a minute before completing.
(2015-09-10, 16:41)J_E_F_F Wrote: I don't see anything crazy there with t.a.t.u. Upon boot it goes through the database twice, slowly the first time and goes right through t.a.t.u, then it runs through very quickly the 2nd time. It runs A-Z and then back tracks and hangs on t.a.t.u for almost a minute before completing.

I don't see any messages in the log when it hangs - I assume this was the hang:
Code:
09:34:51 223.035461 T:1789477888   DEBUG: DoScan Skipping dir 'smb://FILE-SERVER/Music/ZZ Top/1992 - Greatest Hits/' due to no change
09:34:58 229.312759 T:1739334656   DEBUG: Thread JobWorker 1739334656 terminating (autodelete)
09:34:58 229.316772 T:1692398592   DEBUG: Thread JobWorker 1692398592 terminating (autodelete)
09:34:58 229.325790 T:1756111872   DEBUG: Thread JobWorker 1756111872 terminating (autodelete)
09:34:58 229.334030 T:1460257792   DEBUG: Thread JobWorker 1460257792 terminating (autodelete)
09:35:29 260.319305 T:1591735296  NOTICE: ES: Client  from 192.168.0.104 timed out
09:37:03 355.067352 T:1789477888  NOTICE: My Music: Scanning for music info using worker thread, operation took 05:40
09:37:04 355.069763 T:1789477888   DEBUG: Process - Finished scan

What is 192.168.0.104? The smb server or something else?
If you move the Tatu files out of the scanned directory does the stall disappear, or does it just stall at a later item?
192.168.0.104 is my phone with KORE running as a Kodi remote control. Same problem exists on my other RPi2, with a normal remote, not using Kore.
But yes, that appears to be the hang just before the scan finishes and in the scan display window, it always shows the t.a.t.u folder.
(2015-09-10, 14:47)MarkT Wrote:
(2015-09-10, 13:19)polo_joe Wrote: When I was using the same tvheadend config on my x86_64 machine I had no issues so I thought it should be a pi problem.

Also to try: Add dwc_otg.fiq_fsm_mask=0xF in cmdline.txt to enable a USB hack (see this patch for more info).

Tried this cmdline.txt
boot=/dev/mmcblk0p1 disk=/dev/mmcblk0p2 quiet dwc_otg.fiq_fsm_mask=0xF

unfortunately no change.
  • 1
  • 70
  • 71
  • 72(current)
  • 73
  • 74
  • 168

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)10
This forum uses Lukasz Tkacz MyBB addons.