+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: Supplementary Tools for Kodi (https://forum.kodi.tv/forumdisplay.php?fid=116)
+---- Forum: Ember Media Manager (https://forum.kodi.tv/forumdisplay.php?fid=195)
+---- Thread: WIP Developer Area (/showthread.php?tid=165013)
RE: Developer Area - Cocotus - 2014-01-18
While optimizing and working on the metadata scan for ISO images for DVD/Bluray I noticed on my WIN8 64bit system, that metadata scanning with currently provided 32bit MEdiainfo.dll doesn't work anymore on my system - I think thats because of changing the platform from "x86" to "Any". I read a bit and it seems with Switch "Any" Ember wants a 64bit Mediainfo.dll on a 64bit system - after I downloaded and copied the 64bit dll into Ember folder everything worked again. Does this mean from now on we have to provide 32 & 64 bit versions of Mediainfo in Ember? Maybe we should switch back to x86 or is there any advantage with Any? Our applications on my work are alle builded with x86 setting for compatibility reasons.
RE: Developer Area - DanCooper - 2014-01-18
+1
RE: Developer Area - m.savazzi - 2014-01-18
(2014-01-18, 00:25)DanCooper Wrote: This is actually the same solution as that of me.
I want that "sYear = null" is. "Nothing" corresponds to "0".
If "sYear = null" we could do without "If ... else" and always useCode:Movies = _TMDBApi.SearchMovie (sMovie, Page, _MySettings.TMDBLanguage, , sYear)
Do you know what i mean?
WatTMDb only allows "null". So I had to use "If ... else".
I will check more but there is a difference between Nothing (vb) and Null (SQL). I will check what happens.
Now the structure propagates a Nopthing if there is NO sYear parameter in the call
M
(2014-01-18, 11:43)Cocotus Wrote: While optimizing and working on the metadata scan for ISO images for DVD/Bluray I noticed on my WIN8 64bit system, that metadata scanning with currently provided 32bit MEdiainfo.dll doesn't work anymore on my system - I think thats because of changing the platform from "x86" to "Any". I read a bit and it seems with Switch "Any" Ember wants a 64bit Mediainfo.dll on a 64bit system - after I downloaded and copied the 64bit dll into Ember folder everything worked again. Does this mean from now on we have to provide 32 & 64 bit versions of Mediainfo in Ember? Maybe we should switch back to x86 or is there any advantage with Any? Our applications on my work are alle builded with x86 setting for compatibility reasons.
I think the answer is YES. If you move to Any you have to provide the right library/executable for the bit depth you choose.
NuGet does this automatically and is the reason why you have 2 SQLite Interop (32 and 64) in the project
I think I posted the note when I commented the suggestion to move to Any CPU, in any case Dekker500 should put in all the different libraries and make sure the correct one is copied depending on the x86/x64 version.
I think is better to have everything either in Any (and working) or in x86. I think Dekker500's initial concern was that some projects were Any and some were x86 leading to weird results. Correctly he wanted to fix this.
I do not think we will get any real advantage (performancewise) with x64.
M
RE: Developer Area - m.savazzi - 2014-01-18
DanCooper,
I've looked at the sYear point. The issue is the Option Strict that does not allow to propagate a Nothing but requires a CInt(Nothing) that is converted to 0; if you do
Code:
Dim tmpYear As Integer = CInt(IIf(Not String.IsNullOrEmpty(DBMovie.Movie.Year), DBMovie.Movie.Year, Nothing))In other words we have to keep 0 as empty value.
The solution was to change the method in the api and add
Code:
if (year == 0)
year = null;I removed all the IF THEN
RE: Developer Area - DanCooper - 2014-01-18
Great, thx!
Wait for pull request.Have you since today also problems with TMDB?
RE: Developer Area - Cocotus - 2014-01-18
Ah ok I see! I will then put everything to x86 in Ember, include my final iso handling changes and commit
RE: Developer Area - m.savazzi - 2014-01-19
(2014-01-18, 20:16)Cocotus Wrote: Ah ok I see! I will then put everything to x86 in Ember, include my final iso handling changes and commit
Fine for me!
(2014-01-18, 17:36)DanCooper Wrote: Have you since today also problems with TMDB?
Sorry I messed up the TMDB key and the TVDB Key
now everything appear to work That's why I discovered the bug on the interface on wrong and missing strings in the settings dialogs
M
RE: Developer Area - Cocotus - 2014-01-26
Guys as a request from Dan I have submitted a commit to Ember with changes target platform to NET4.5 (before 3.5) for Ember Project. I'm ok with that, cause I prefer always working with updated/improved NET classes of NET4.5. Drawback is that after that you need Visual Studio 2012 or above to load the Ember Project. Here's a quick compatibility list:
Here's a list of supported VS Studio versions:
VS 2008 keyed to .NET 3.5 and can use 2.0 and 3.0. CANNOT use 4.0 or 4.5
VS 2010 keyed to .NET 4.0 and can use 3.5, 3.0 and 2.0. CANNOT use 4.5
VS 2012 keyed to .NET 4.5 and can use 4.0, 3.5, 3.0 and 2.0
If you need features introduced in .NET Framework 4.5, you need VS 2012/VS2013
Anyone of us developers working with Visual Studio 2010 and lower?!
RE: Developer Area - locuester - 2014-01-26
I'm on VS 2013, and am very happy with going to 4.5! One of the reasons that I have jumped in this project is to optimize performance... I have decades of experience in development and performance optimization and Ember could really use some cleanup in that area. By moving to .NET 4.5 I can leverage Async and Await to quickly optimize the parellel operations of scraping since currently it is VERY slow, and mostly wasted in native wait states.
Love the work you guys put in, and while my life is too busy to commit as much time as I'd like, I'd love to own the performance of scraping task. I will probably do a sprint next weekend.
-D
RE: Developer Area - m.savazzi - 2014-01-26
(2014-01-26, 01:56)Cocotus Wrote: Guys as a request from Dan I have submitted a commit to Ember with changes target platform to NET4.5 (before 3.5) for Ember Project. I'm ok with that, cause I prefer always working with updated/improved NET classes of NET4.5.
GREAT!
Go ahead
(2014-01-26, 06:28)locuester Wrote: I'm on VS 2013, and am very happy with going to 4.5! One of the reasons that I have jumped in this project is to optimize performance... I have decades of experience in development and performance optimization and Ember could really use some cleanup in that area. By moving to .NET 4.5 I can leverage Async and Await to quickly optimize the parellel operations of scraping since currently it is VERY slow, and mostly wasted in native wait states.
Love the work you guys put in, and while my life is too busy to commit as much time as I'd like, I'd love to own the performance of scraping task. I will probably do a sprint next weekend.
-D
Great to have you onboard.
I think there are some issues in the GUI process against the inner threads that lead to deadlocks (like the external notifications).
At the foundation of 1.4 there is the renewed scraping process and scrapers where I tried to have all the time consuming items in separate / multiple threads on one side and to minimize the download of information both in terms of size (scraping whole fullhd image just to resize it as a thumb was not exactly efficient) and repetitions.
I would ask you to look into the modules mechanism before jumping in the scraper modules as there could be some low hanging fruits there
Do you think we need to move to XAML + MVVM to bring ember to the next level and take full advantage of .NET 4.5?
RE: Developer Area - locuester - 2014-01-26
My advice:
We should shoot for a stable .NET 4.5 build with minimal changes just to have a stable and functional base to work from. In it's current state, I have to load up an older Ember release to have the scraping done, and that should be priority 1 fix. Aside from that, low hanging fruit fixes and module work is ok, but really we need the core to be stable and functional first. Then we can branch a XAML+MVVM.
RE: Developer Area - m.savazzi - 2014-01-26
Ok, agreed.
question: which issues you have with 1.4? I use it for my scraping...
RE: Developer Area - DanCooper - 2014-01-26
There are many (small) issues. Next I will fix is handling while TMDB error.
RE: Developer Area - Dekker500 - 2014-01-27
A major one for me is manually adding trailers on a 64-bit system will crash it... Anyone else on Win7 64-bit have a similar problem, or just me?
RE: Developer Area - locuester - 2014-01-27
I'm on 64-bit and most of the scraper stuff just doesn't work. I saw some activity around that so I was just going to sit tight and work on some modules. I'll keep upstream merges flowing into my fork and continue testing - but at this time I'm not actively debugging why it's erroring out. If I need to debug that here on 64-bit, please let me know.