2015-04-06, 18:09
It's not possible to compile Ember in x64. I'm still waiting for a working x64 version of VLC Player.
(2015-04-07, 21:04)AviBueno Wrote: The rational for a 64-bit software would be to let a process have access to more than 2GB RAM (which is the limit of a 32-bit process).
If VLC is doing so well as a 32-bit app, I believe that EmberMM could cope with this "limitation" as well.
Personally, I'd drop the x64 configuration from the .sln file as currently it does more harm than good.
(*) If and when it will be relevant (e.g. VLC do support x64), the configuration can be re-created with a flick of a button.
My $00.02.
SELECT DISTINCT movielist.* FROM MoviesVStreams INNER JOIN movielist ON (MoviesVStreams.MovieID = movielist.idMovie) WHERE MoviesVStreams.Video_Height = '720';
SELECT * FROM movielist WHERE Video_Height = '720';
(2015-04-09, 22:06)Cocotus Wrote: Oh another idea: "movielist" itself is a view in Ember I guess. It contains the most basic information for a movie like genre, studio and such in a single view. Last time I checked the audio and video metadata weren't part of that view - any chance to include them so I don't need to write up such a long SQL query like I did before:
Code:SELECT DISTINCT movielist.* FROM MoviesVStreams INNER JOIN movielist ON (MoviesVStreams.MovieID = movielist.idMovie) WHERE MoviesVStreams.Video_Height = '720';
I thought something like this would be easier:
Code:SELECT * FROM movielist WHERE Video_Height = '720';
(2015-04-10, 20:15)m.savazzi Wrote: Team,
I tried to join my changes with the await/async but there are quite a number of conflits... so I cannot do the merge but Dan has to do it (sorry for that).
Do you think we can now do the merge? I'm worried if we continue to add functionalities the merge will become impossible and all the work on await/async will have to be redone.
If we decide not to merge the await/async (bhooooo ) there is a lot of work to to on the events and dialog opening in the file download and a lot of other bottlenecks to fix... as well as to rewrite some of the scrapers using vb.net libraries instead of C#.
Even after they will have to be fixed but are much more easy... so I was keeping on hold waiting for the new version
Let me know how you'd like to proceed...
(2015-04-10, 20:37)Cocotus Wrote: thoughI believe there WILL be problems after Dan merges this massive commit!
(2015-04-07, 21:04)AviBueno Wrote: The rational for a 64-bit software would be to let a process have access to more than 2GB RAM (which is the limit of a 32-bit process).
If VLC is doing so well as a 32-bit app, I believe that EmberMM could cope with this "limitation" as well.
Personally, I'd drop the x64 configuration from the .sln file as currently it does more harm than good.
(*) If and when it will be relevant (e.g. VLC do support x64), the configuration can be re-created with a flick of a button.
My $00.02.
(2015-04-11, 09:32)m.savazzi Wrote:(2015-04-07, 21:04)AviBueno Wrote: The rational for a 64-bit software would be to let a process have access to more than 2GB RAM (which is the limit of a 32-bit process).
If VLC is doing so well as a 32-bit app, I believe that EmberMM could cope with this "limitation" as well.
Personally, I'd drop the x64 configuration from the .sln file as currently it does more harm than good.
(*) If and when it will be relevant (e.g. VLC do support x64), the configuration can be re-created with a flick of a button.
My $00.02.
Do not remove the X64, just compile the X86.
Once we move to a real, full parallel threading taking advantage of 64 bit could be good
Even if I do not think I will download more than 2GB of images in one shot... who ever knows