home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
General Development (no feature request here!)
Custom Data Grabber including Sky UK Channel/EPG Grabber
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="ears" data-source="post: 1090322" data-attributes="member: 83203"><p>Upgrade installer would work, it just takes the source code for the grabber further and further away from the original MP code which will make merging when 1.9 comes out more of a pain. The more changes I make, the harder it'll be for the next person to merge. The other option is to simply not check the changes in, but then when the next person merges on 1.9 the upgrade installer disappears and they have the same problem. Or that's what my limited understanding of git leads me to believe.</p><p> </p><p>A lot of the logic for the installer is written in C# and I got quite used to it. I think the ideal really in this situation is to add new things rather than change existing. So I could put a little check in the database creation and upgrade checks to see if the 3 required fields exist. If not run an extra little SQL query, outside the serial upgrade path of the existing queries, that creates them. That way it should never get missed by the database version control checks, as it is being now. I haven't spotted, yet, how this was handled in earlier versions when the user was installing the version afresh, then running DJBlu's custom installer, effectively upgrading to the same version.</p><p> </p><p>I'll have a look tonight but if you want the SQL you need to run just let me know.</p><p> </p><p>PS I'm very new to Mediaportal - if anyone knows its structure better than me, and thinks I'm mad, feel free to let me know.</p></blockquote><p></p>
[QUOTE="ears, post: 1090322, member: 83203"] Upgrade installer would work, it just takes the source code for the grabber further and further away from the original MP code which will make merging when 1.9 comes out more of a pain. The more changes I make, the harder it'll be for the next person to merge. The other option is to simply not check the changes in, but then when the next person merges on 1.9 the upgrade installer disappears and they have the same problem. Or that's what my limited understanding of git leads me to believe. A lot of the logic for the installer is written in C# and I got quite used to it. I think the ideal really in this situation is to add new things rather than change existing. So I could put a little check in the database creation and upgrade checks to see if the 3 required fields exist. If not run an extra little SQL query, outside the serial upgrade path of the existing queries, that creates them. That way it should never get missed by the database version control checks, as it is being now. I haven't spotted, yet, how this was handled in earlier versions when the user was installing the version afresh, then running DJBlu's custom installer, effectively upgrading to the same version. I'll have a look tonight but if you want the SQL you need to run just let me know. PS I'm very new to Mediaportal - if anyone knows its structure better than me, and thinks I'm mad, feel free to let me know. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
General Development (no feature request here!)
Custom Data Grabber including Sky UK Channel/EPG Grabber
Contact us
RSS
Top
Bottom