Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Lasse_Lus]

What has happend to large text ? it's almost impossible to edit any text in notes or large value fields

it's really slow like sirap and CPU goes up to 100 %

...so i thought, has it always been like this ? so i gave it a try in MC14 (with same db), and there it works pretty well, no lags even though CPU goes high there as well..

..so i thought can it be me, since nobody has reported it, so i tried it on an other computer, and it the same, MC 14 work well and MC 15 not...

even an empty db with 1 "large" note lags, so it's not the number of files...

can this be fixed, please ?

thanks

Lars

[JimH]

In notes, try turning the option to show fields off and on.  Right click, show field labels.

[Lasse_Lus]

sorry jim, that does not make any difference, AND it's the same lag in the action Tag window window when editing large text..something is not correct in MC15

[JimH]

What do you mean by large text?

[Lasse_Lus]

(large text = quite a lot of characters) something like this from yesterday

Yes.  Being a licensed Blu-ray player means a *LOT* of draconian things. I can't believe the audiophile crowd would even suggest integrated, native BD playback for that simple reason.  Let's take a look at some of the things a licensed player is forced to do:

-First and foremost, it needs to support AACS decryption in a way that prevents the player key from being lifted from memory.

That means debuggers need to be trapped, memory needs to be wiped clean, and all kind of other nasty nonsense that could, and probably would, introduce instability in MC15.

-Next up you have BD+.  This is another whole new ballgame and requires a BD+ machine implementation that is also secure from hacking.  And as new titles make use of more and more BD+ functions (there are a lot), the player will most likely have to be tweaked to handle it.  And since ArcSoft didn't even seem to get a heads up with the new Avatar BD+ protection was released, I suspect JRiver would also be forced to play catch up when the BD+ protection is changed.  Playing catch up is never a good place to be in when you're a developer and customers are clamoring for a fix for their new Blu-ray.

-For you audiophiles in the house, we have bitstreaming and non-downsampled decoded LPCM.  This is a really fun topic.  For bitstreaming, a Protected Audio Path is required.  JRiver would in fact be required to implement each and every vendor's interpretation of PAP.  What I mean is, nVidia does PAP one way, ATI does it another way, Realtek does it another way, ASUS Xonar does it yet another way.  You will be writing code to support each and every new card that comes out in order to support PAP for bitstreaming.  That also applies to non-downsampled LPCM for those that couldn't care less about bitstreaming.  No PAP....no non-downsampling.  There is a strange use case exemption that seems to be out there, but, that use case isn't fully understood yet so discussion it here is premature at best.

-For videophiles, HDCP is also required to be supported by the player.  IOW, more DRM code that doesn't achieve anything for the end user but a headache that the developers will have to focus on.

Why do I bring all this up?  All of that coding equals an ENORMOUS amount of time and effort.  That's time and effort that will NOT be spent improving other areas of MC15.

 We need to remember that developer resources for a company the size of JRiver are not infinite.  If they're working on DRM requirements to not get their AACS LA provided license revoked, they're not working on other areas of the code.  If they were to hire developers specifically for the purpose of doing all the DRM coding, the cost would have to go up because they still need to cover the AACS LA license fee, PLUS pay the developers working on the code. And let's not even get into the exponential cost of testing.

 The in house hardware requirements alone aren't cheap as you need to test on a wide variety of hardware to make sure the DRM plays nice.  I'm not pointing all this out to be negative.  I'm pointing it out to clearly define the reality behind such an endeavor.  It's not cheap from a labor or monetary standpoint.  And other areas of the code would likely suffer as a result.

 Just look at PowerDVD for a prime example of that.  I just want everyone to have a clear picture of what would be needed to provide licensed, official BD support.  BTW, did I mention the work necessary to create the video and audio codecs?  Those aren't provided.  As an AACS LA licensee, you get the spec.  You're on your own as to how to implement it.  That's 3 video codecs (already handled so no problem there) and 3 audio codecs.  DTS-HD MA being the most obvious one that would need to be written from scratch.  I think TrueHD could be handled by what's already out there depending on how the license is written.  Otherwise they may be forced to write their own codec for it.  Awesome....

this work ok in MC 14 not in MC 15

maybe auto correct spelling is a thief here ? but that does not explain the lag in the action window or ?

[JimH]

Try right click, HTML View, just to test.

[Lasse_Lus]

Try right click, HTML View, just to test.

i tested, no difference...you could try to paste above text from samuari into field [description] and into a note and you will see that it lags..then try MC 14

[gappie]

i tried the text in notes and it slows down a lot indeed. in description it works fine on my machine though.

 
gab

[JimH]

I see a lag, but it isn't terrible.  Maybe you're using a lower power machine.

Editing notes did change.  There is a lot going on behind the scenes.

[Lasse_Lus]

I see a lag, but it isn't terrible.  Maybe you're using a lower power machine.

Editing notes did change.  There is a lot going on behind the scenes.

i do have a low power machine 2,66 ghz, but i do find it odd that i cant edit text and that is working so much better in MC 14..


behind the scenes  like that