INTERACT FORUM
More => Old Versions => JRiver Media Center 19 for Windows => Topic started by: JimH on August 07, 2013, 10:01:44 am
-
We've ported MC to Mac. Now we're working on Linux. What's in it for you? This subject came up on the beta board, so I thought we might talk about it here.
Why are we doing it? A couple of reasons. First, it's good for JRiver to broaden our customer base. Second, the OS world is much more fragmented than it was ten years ago when Windows dominated. Third, JRiver has cross platform roots. Our main focus, from 1987 until about 2000, was cross platform. We had a product called ICE.TCP, which connected Windows and Linux. In fact the Windows client software was originally on DOS.
Why should you care?
Matt's first answer was "We'll be in business." I laughed, but it's true. We must do it.
It also makes our code more valuable. It's free of Windows dependencies, so it's much easier to port to any future OS.
We control all our code, so if there's a bug, we can fix it.
In rewriting some of the code, we've also been able to speed it up.
If we can continue to increase our sales significantly, as we have done the last several years, we will be able to hire more talent, and move faster.
-
+1 ..........but without loosing focus on quality!
-
Jim
Any plans for JRiver on Android?
-
Not yet. It would probably mean rewriting everything in Java.
-
+1
Sweet - would love to get my HTPC off of windows!
-
It's free of Windows dependencies, so it's much easier to port to any future OS.
[tease] Wow I didn't realise you got rid of the dependency for Windows DirectShow! ;D It will be an industry first running ROHQ (lav and mad) on Unix and OSX! [/tease]
-
Not yet. It would probably mean rewriting everything in Java.
Please not a Java code base - I like how MC is nice and quick
-
Please not a Java code base - I like how MC is nice and quick
+1, Java is a slug.
To make Java perform, you need to write everything native and provide a single JNI call to run the native implementation.
Java: "Write Once, Run There".
-
Just want to point out that there is the NDK (Native Development Kit) (http://developer.android.com/tools/sdk/ndk/index.html) for Android, which is great for keeping core functionality in C/C++, thus eliminating performance concerns and reducing porting efforts.
You probably would still want to write a custom UI in Java, though.
-
I think there is no need for full MC in android. Better client on the other hand would be most welcome even if it would cost some money. Current Gizmo simply isn't enough.
-
Well, the idea of being able to run MC Library Server from a linux based NAS is nice
-
I see all kind of very low cost Android boxes
(http://www.gadgetgear.nl/wp-content/uploads/2013/07/Minix-Neo-G4-Unboxing.jpg)
Attach a DAC and you have your audio server.
This is a fast growing market
Where is JRiver?
-
Our main focus, from 1987 until about 2000, was cross platform. We had a product called ICE.TCP, which connected Windows and Linux. In fact the Windows client software was originally on DOS.
Why should you care?
Matt's first answer was "We'll be in business." I laughed, but it's true. We must do it.
Jim
Any plans for JRiver on Android?
From Jim's comment, it's clear that JR are working from their strengths. So a Linux direction for "where to next?" makes eminent sense in terms of speed of delivery and quality of end product.
I love the interest that these kind of initiatives generate. User enthusiasm easily goes beyond developer announcements at any point in time, so I'd caution patience. That said, it's clear that Android is going places:
http://www.eweek.com/mobile/android-apple-lead-smartphone-os-market-share-idc/ (http://www.eweek.com/mobile/android-apple-lead-smartphone-os-market-share-idc/)
http://www.webpronews.com/android-almost-reaches-80-percent-global-market-share-in-q2-2013-08 (http://www.webpronews.com/android-almost-reaches-80-percent-global-market-share-in-q2-2013-08)
So, Vincent is asking the right question.
-
Please not a Java code base - I like how MC is nice and quick
Yes Java is slower than C++. However it's the best choice in many business apps... Software talent that can deal with C++ pointers and memory management is more expensive than faster servers. I switched from all C++ to mostly Java in my final years working before retirement. The write-once, run anywhere was pretty cool, but I did miss what they removed from C++ (operator overloading and data protection). I used to promote my skills with C++ memory management and pointers on my resume... oh well... times change. Java is really an improvement over C++ in that, over the years... I found most developers really never ever did get memory management and pointers. I was constantly being forced to develop to the lowest common developer. I was once told to never ever use function pointers, since the rest of the team (when in NJ) couldn't maintain the code.
-
.. Java is really an improvement over C++ in that, ...
Java still can have memory leaks, it hasn't addressed all memory problems.
It also is a lot harder to reliably benchmark because of the underlying layers. No more counting instructions and clock cycles.