[luksol]

Alright.... I will rename my 3000 episodes at some point ... :/

Try filebot ( http://www.filebot.net ), may speed things up

[mikeb93]

Looking more closely at
http://wiki.xbmc.org/index.php?title=Nam...s/TV_shows

It looks like files must be named:
"anything_101.mkv" or "anything.101.mkv"

It doesn't explicityly state that "101.mkv" is a valid name.
I don't know for certain, but it might be worth trying renaming the file to start with something before the 101. Then do a clean and scan.
If that helps, then that may be an easier rename to script.

Well then I wonder why it works for like 99% of my library but screws up for like 10 episodes or so.
Funny thing is, that those duplicates just show to another episode of a later season.

[Milhouse]

Well then I wonder why it works for like 99% of my library but screws up for like 10 episodes or so.
Funny thing is, that those duplicates just show to another episode of a later season.

To be honest, as this is core functionality, you'd stand a better chance of getting an answer to that question by posting a new thread in the General section. If someone submits a pull request with a fix that is likely to be merged upstream, I'll happily include it.

Or you could just rename those 10 episodes so that there is no ambiguity.

[goRt]

I know how much the dev like mySQL, I'm getting a videoDB upgrade issue when going beyond v79 (which includes the dreadful multi series issue):
http://forum.xbmc.org/showthread.php?tid=201785

Is there a fix or an alternate DB that XBMC can use to replace mySQL

Thanks

Replied in your other thread, this looks more like a server rather than application issue.

Thanks Milhouse, but further testing has demonstrated that the upgrade is producing the data - with the same 99% of 64mb available previous versions require 3-6% whereas v88 onwards fails in short order having got to 100%.

I notice that the developed (of xbmc) doesn't like MySQL and indicates it has put support for that on hold. The wiki recommends the use of MySQL in this scenario.

Thanks

[Milhouse]

Thanks Milhouse, but further testing has demonstrated that the upgrade is producing the data - with the same 99% of 64mb available previous versions require 3-6% whereas v88 onwards fails in short order having got to 100%.

I notice that the developed (of xbmc) doesn't like MySQL and indicates it has put support for that on hold. The wiki recommends the use of MySQL in this scenario.

Thanks

How large is your tvshow library (how many tvshows, seasons and episodes)?

You should be able to reproduce the problem by running the same query (SELECT * FROM seasonview WHERE seasonview.idShow = N) where N is a valid tvshow id, in your case 405, using any client, eg. MySQL Workbench.

Testing here on a fairly low powered NAS (HP N36L, approximately Atom-class with 8GB RAM, v89 db) and this query completes in less than 0.281 seconds. Running without the WHERE clause returns 215 rows and completes in 0.297 seconds. This is for a library with 61 tvshows, 215 seasons and 2992 episodes, and produces scratch files of less than 100KB:

Code:

-rw-rw----  1 mysql  wheel  71752 Aug 13 17:59 /tmp/#sql1113_816e2_1f.MYD
-rw-rw----  1 mysql  wheel   1024 Aug 13 17:59 /tmp/#sql1113_816e2_1f.MYI

If your tvshow library is not ridiculously large, maybe there's a problem with the database (ie. with one or more of the indexes) that could be fixed by running repair on one or more of the tables that make up the view. Note that I'm not a MySQL expert so you'll need to Google for more information on the repair command (or open a new thread to discuss this issue, just so you get more eyes-on as it's not particularly relevant to the Pi).

Do you still have this problem with v89 (which my latest builds are using)?

[Milhouse]

New OpenELEC Helix build: #0813
(Supercedes previous build)

Code:

# uname -a
Linux rpi512 3.16.0 #1 PREEMPT Wed Aug 13 22:09:01 BST 2014 armv6l GNU/Linux

# vcgencmd version
Aug 12 2014 18:21:28
Copyright (c) 2012 Broadcom
version f32b2bbfdea55d48c9a52b92e5c798f9aa5f47bc (tainted) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20140813220749-r18964-g5c12231

Based on tip of OpenELEC master (5c122313, changelog) and tip of XBMC master (0abbe2d0, changelog) with the following modifications:

• Includes newclock3 patches
  
• Excludes the OpenELEC fernetmenta patches due to conflicts with newclock3
  
• Excludes the OpenELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-3.16.y
  
• Excludes the OpenELEC xbmc-001-newclock3 patch in favour of sourcing these and possibly more recent patches directly from newclock3 branch
  
• Default setting for "Show RSS Feed" changed to disabled
  
• Disabled "Total Duration" in Confluence (see build #0221 for details)
  
• Includes latest libnfs master
  
• Includes latest libcec master
  
• Includes libcec double-key suppression.
  
• Includes libcec CEC Standby Fix.
  
• Increase scan interval of PeripBusCEC from 5000 to 60000, reducing CPU loading by about 2% (1GHz Pi) every 5 seconds (even when CEC is "disabled")
  
• Includes CONFIG_COREDUMP=y to allow creation of coredumps
  

Build Highlights:

1. newclock3-based build.
   

Build Details:

1. OpenELEC:
   • lm_sensors: link -lsensors static
     
   • Revert "remove package: nasm"
     
   • Revert "toolchain: dont build package 'nasm'"
     
2. XBMC:
   • [keyboardlayouts] add Hebrew (PR:5207, 1 commit, 1 file changed)
     
   • [keyboardlayouts] add Bulgarian (PR:5205, 1 commit, 1 file changed)
     
   • [keyboardlayouts] add AZERTY layout (PR:5211, 1 commit, 1 file changed)
     
   • [cosmetic] cleanup .gitignore (PR:5186, 1 commit, 1 file changed)
     
   • [AirTunes] - don't handle the flush callback from shairplay - we handled (PR:5214, 1 commit, 2 files changed)
     
   • fixed: keyboardlayouts - proper xml
     
   • [language] missed some xbmc/kodi replacements
     

[d0wnl0rd]

You should be able to reproduce the problem by running the same query (SELECT * FROM seasonview WHERE seasonview.idShow = N) where N is a valid tvshow id, in your case 405, using any client, eg. MySQL Workbench.

Testing here on a fairly low powered NAS (HP N36L, approximately Atom-class with 8GB RAM, v89 db) and this query completes in less than 0.281 seconds. Running without the WHERE clause returns 215 rows and completes in 0.297 seconds. This is for a library with 61 tvshows, 215 seasons and 2992 episodes, and produces scratch files of less than 100KB:

Just to give you a benchmark on a really low-powered NAS: mysql running on Synology DS210j provides me with 3,0x seconds running that query with a N-parameter (giving 4 rows), and 3.1x secondy for a full query (giving 231 rows). 81 tvshows, 458 seasons, 3.241 episodes.

The same query on nearly the same amount of data running on version 88 provides consistently half a second faster runtime. (87, 86 on the same level as 89)

(scratch head)
Does anyone know how to get an execution plan on mysql?
UPDATE: If I expand the query and enter the search criteria directly e.g. to:
select `seasons`.`idSeason` AS `idSeason`,`seasons`.`idShow` AS `idShow`,`seasons`.`season` AS `season`,`tvshowview`.`strPath` AS `strPath`,`tvshowview`.`c00` AS `showTitle`,`tvshowview`.`c01` AS `plot`,`tvshowview`.`c05` AS `premiered`,`tvshowview`.`c08` AS `genre`,`tvshowview`.`c14` AS `strStudio`,`tvshowview`.`c13` AS `mpaa`,count(distinct `episodeview`.`idEpisode`) AS `episodes`,count(`files`.`playCount`) AS `playCount` from (((`seasons` join `tvshowview` on((`tvshowview`.`idShow` = `seasons`.`idShow`))) join `episodeview` on(((`episodeview`.`idShow` = `seasons`.`idShow`) and (`episodeview`.`c12` = `seasons`.`season`)))) join `files` on((`files`.`idFile` = `episodeview`.`idFile`)) and seasons.idShow = 25) group by `seasons`.`idSeason`
then I do get an execution time of about 0,5x seconds.
So it looks to me as if the view is populating the complete dataset and only then it will be filtered according to the criteria.

[Milhouse]

Experimental newclock4 build uploaded: #0813b

Same as build #0813, but with newclock4 patches in place of newclock3. See here for details.

newclock4 additions since previous build #0812b:

• omxcodec: squash logging
  
• omxcodec: Enable decodeonly
  
• omxcodec: Remove unused
  
• omxcodec: Initial deinterlace support (currently disabled)
  

[Milhouse]

Just to give you a benchmark on a really low-powered NAS: mysql running on Synology DS210j provides me with 3,0x seconds running that query with a N-parameter (giving 4 rows), and 3.1x secondy for a full query (giving 231 rows). 81 tvshows, 458 seasons, 3.241 episodes.

Another factor may be the amount of RAM available to the MySQL server instance. Relational databases love memory more than horsepower, but a database starved of RAM may be forced to hit the scratch area much harder. Much of this is "tuneable" in my.cnf assuming you have the RAM to spare. My configuration is custom (FreeNAS with MySQL running in a jail) and RAM isn't really an issue which may mean it has to use the scratch area much less (if at all). For reference, here's the my.cnf I'm using (dual-core processor, 8GB RAM).

I would suggest continuing this discussion in the goRt's thread as it's not Pi specific and may get more attention from non-Pi users that may also be impacted by this (if not now, then eventually). If there are any changes/optimisations forthcoming on the schema side of things I'll be sure to include them in a future build.

[Milhouse]

New OpenELEC Helix build: #0814
(Supercedes previous build)

Code:

# uname -a
Linux rpi512 3.16.0 #1 PREEMPT Thu Aug 14 22:39:40 BST 2014 armv6l GNU/Linux

# vcgencmd version
Aug 12 2014 18:21:28
Copyright (c) 2012 Broadcom
version f32b2bbfdea55d48c9a52b92e5c798f9aa5f47bc (tainted) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20140814223115-r18997-g65b4bdd

Based on tip of OpenELEC master (65b4bddc, changelog) and tip of XBMC master (add0e1b3, changelog) with the following modifications:

• Includes newclock3 patches
  
• Excludes the OpenELEC fernetmenta patches due to conflicts with newclock3
  
• Excludes the OpenELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-3.16.y
  
• Excludes the OpenELEC xbmc-001-newclock3 patch in favour of sourcing these and possibly more recent patches directly from newclock3 branch
  
• Default setting for "Show RSS Feed" changed to disabled
  
• Disabled "Total Duration" in Confluence (see build #0221 for details)
  
• Includes latest libnfs master
  
• Includes latest libcec master
  
• Includes libcec double-key suppression.
  
• Includes libcec CEC Standby Fix.
  
• Increase scan interval of PeripBusCEC from 5000 to 60000, reducing CPU loading by about 2% (1GHz Pi) every 5 seconds (even when CEC is "disabled")
  
• Includes CONFIG_COREDUMP=y to allow creation of coredumps
  

Build Highlights:

1. newclock3-based build.
   

Build Details:

1. OpenELEC:
   • corefonts: move to virtual/
     
   • alsa: move to virtual
     
   • initramfs: move to virtual
     
   • linux-drivers: move to virtual
     
   • linux-firmware: move to virtual
     
   • mediacenter: move to virtual
     
   • network: move to virtual
     
   • remote: move to virtual
     
   • toolchain: move to virtual
     
   • x11: move to virtual
     
   • atvclient: move out of remote
     
   • eventlircd: move out of remote
     
   • lirc: move out of remote
     
   • irserver: move out of remote
     
   • libdvbcsa: move to multimedia
     
   • vdr: move to package multimedia
     
   • vdr-wirbelscancontrol: move to package multimedia
     
   • vdr-wirbelscan: move to package multimedia
     
   • vdr-satip: move to package multimedia
     
   • vdr-plugin-xvdr: move to package multimedia
     
   • vdr-plugin-xmltv2vdr: move to package multimedia
     
   • vdr-plugin-vnsiserver: move to package multimedia
     
   • vdr-plugin-streamdev: move to package multimedia
     
   • vdr-plugin-eepg: move to package multimedia
     
   • vdr-plugin-dvbapi: move to package multimedia
     
   • vdr-live: move to package multimedia
     
   • vdr-iptv: move to package multimedia
     
   • vdr-epgsearch: move to package multimedia
     
   • vdr-dummydevice: move to package multimedia
     
   • vdr-control: move to package multimedia
     
   • alsa-lib: move to package audio
     
   • alsa-utils: move to package audio
     
   • debug: move to virtual
     
2. XBMC:
   • Added limit attribute for the directory provider (PR:4330, 2 commits, 4 files changed)
     
   • [Fix] Stale metadata/cover art when using airplay audio mirroring (PR:5209, 1 commit, 2 files changed)
     
   • videodb: fix GetMusicVideoAlbumsNav() in combination with masterlocks (fixes #15385)
     
   • [Confluence] rename lyrics window
     
   • [Confluence] fix: lyrics window not showing up
     

[steve1977]

Thanks again for all the builds. Which would be the right one if I were to switch to Helix Alpha 2?

[Milhouse]

Thanks again for all the builds. Which would be the right one if I were to switch to Helix Alpha 2?

Alpha 2 is based on v88 of the videodb schema while my latest build is currently using v89, but other than that you should be able to switch between the latest build and Alpha 2.

If you want to stick with v88 because of other non-Pi Alpha 2 clients, the last v88 build of mine is #0804.

[steve1977]

Thanks for your quick reply. I am currently using Gotham on my non-pi clients. Library scanning is so super-slow on my pi though that I want to try Helix, which I read in the other thread has fixed a potential issue on this. Is there any issue to using v89 on my pi and Gotham 13.1 on my non-pis?

[Milhouse]

Thanks for your quick reply. I am currently using Gotham on my non-pi clients. Library scanning is so super-slow on my pi though that I want to try Helix, which I read in the other thread has fixed a potential issue on this. Is there any issue to using v89 on my pi and Gotham 13.1 on my non-pis?

If you're not using MySQL, there shouldn't be any issue.

[steve1977]

Ok, so the Helix "fix" is only for the treatment of mysql? I saw this on the XBMC blog for Helix Alpha 2: "Library Improvements
The Kodi Library is getting improvements both coming in and going out. On the input side, library scanning is receiving a massive speed boost, which should make the initial scan on Android and iOS devices quite a bit more spritely."