Avoid firmware update 2.08.13.

Tinwarble wrote:

I have looked through the OSD folder for the new firmware though and I can’t see any changes from the previous as to the music images.

it is a smybol I haven’t seen before, white-ish background and a music note (blue-ish) in the front, I checked all my no cover art images and they are supposed to work. If it is interesting i make a picture

Yeah, that’s interesting.  I was looking through the OSD and it seems as though there are also some corrupted images.

If you want to, post me a pic.  I’m not going to spend much time with this update, but if you let me know what problems you might see I’ll try to get them pushed along to the right people.

that would be genuinely great if you could.

my No Cover Art image is underneath that one, i obviously know all the images in my theme so I am surprised where this is coming from all of a sudden.

Snpashot of audio run

same thing on all other themes including yours

Hmmm, that’s odd DeVicious.  I looked through the entire OSD folder for the new firmware and could not find that image anywhere.

Just to make sure that we’re on the same page.  You said that it’s not the image that you have in your theme for “music_gallery_grid_no_cover_art.png”?  Also, does this show up for everthing or just for albums that you don’t have ablum art for?

You can try this to see if it shows the same image.  First rename you music no cover icon to “music_gallery_grid_no_cover_art2.png”, then open the “album_playback.xml” and change the line in the xml to reflect the new name.  Then reapply your theme and see if you have the same thing happening.

this is odd indeed, this behavior only appears when there is no cover art, if cover art is available it shows correctly.

In order to learn faster and in order to make it more comfortable for modders to mod my theme I am preparing a PDF File with documentation for dummies, one of the features is a catalogue of ANY image and a “how to” replace it. What you suggested with the renaming to music_gallery_grid_no_cover_art2.png I have already tried and thought of as on option for modders for these 2 images  DEMO IMAGES

For that matter I wen’t further and used an entirely different name and put it into the xml file and nothing changed at all.

I appears to me that not only in this XML file and also in the Gallery View parts of the XML reference is completely ignored.

Just to be thorough i tested this ony all other mode themes I have and the same thing happens. There has been a change in the database and this image is completely strange to me as I don’t have it anywhere on the hub or my HDD.

Another thing I don’t get is in the video_run.xml

this line…

<image image="@@file_album" default_image="@@default_thumbnail" x="45" y="455" w="163" h="248" align="hcenter" scale_type="fixratio" scale="100" selected_scale="100"/>

 … now it completely ignores the @@file_album and instead of the cover art it seems to skip to “video_browse_gallery_thumbnail_default.png”

I went ahead to changed the image to a solid black and instead of displaying a rectangle cover shaped black image it showed a perfect square 163x163 pixels. WEIRD

and don’t even get me started on the Gallery View, it is not even fixable, it is now necessary to produce thumbnails (filename.jpg) in the exact same size as requested from the xml. Otherwise it will be cropped no matter what alignment it will crop 2 pixels on the right and on bottom.

The X & Y coordinates are fantastical, there is a misbehavior of 27 pixels towards the bottom. I am not sure what they were trying to fix but in my opinion they have crashed the hubs firmware with a dumbo version that doesn’t even work correctly on the mochi theme. SIGH

Yeah, I’ve already mentioned the missing sizing/alignment data.  But there does seem to be some really odd behavior as far as the imaging.  As I’ve said I haven’t really had much time to play around with the firmware and I have already rolled back to the previous version.  When I have some time though I’ll reload the new firmware and take a look to see if I can figure out what’s going on.

Just a thought though, you may want to try reflashing the firmware to see if that corrects anything.  The process is the same as rolling back the firmware, just change the version number to a higher one in the .ver file then update again.  I would also try it with a fresh download, sometimes the firmware can get corrupted either during the download process or during the flash.  Not to say that its what’s happening, but it wouldn’t hurt to make sure.

Also, I’m uploading the new OSD as I type this and I’ll post the download link tomorrow sometime.  You can download it and compare the new xmls with the old ones in your theme and see if there’s any difference.

Can we avoid some of the new firmware and keep other parts of it like some of the service upgrades? Just wondering if the firmware upgrade is an all or nothing deal? I am rolling back anyway as I spent way, way to much time building my hub around MOJO 1.10.2 (MS) with Trickle to live without.

Thanks for you time!! You do great work Tinwarble.

Well, I glad you like Mojo and Thank you.  But no, you can’t keep parts of the new firmware, it is and all or nothing thing.  Hopefully though, they’ll get the bugs out of the next release.

Tinwarble wrote:

Also, I’m uploading the new OSD as I type this and I’ll post the download link tomorrow sometime.  You can download it and compare the new xmls with the old ones in your theme and see if there’s any difference.

    • *> * * *
      Tinwarble wrote:

Also, I’m uploading the new OSD as I type this and I’ll post the download link tomorrow sometime.  You can download it and compare the new xmls with the old ones in your theme and see if there’s any difference.

    • *> that’s nice, thank you!> btw i re-flashed it and still the same misbehaviors and images as mentioned earlier

Yeah, I didn’t think that it would, but I thought it would be worth a try.

You can download the OSD from HERE.

Okay I decided to keep digging and was surprised to find thumbnails for each View Page in the thumb folders.

I decided to compare them with the original and by looking even closer i found way more mistakes

CHECK THIS OUT

In one image it either cuts pixels from the middle or compresses the image that much that an entire frame that sourounds the poster wen missing. The overall compression is horrible and while they make us believe they changed the loading times of the backdrops they simply tempered with the thumbnail file size which makes browsing appear to be faster but on a high end tv this is more like pixelation mania.

I stand my by statement, this is unusuable and if they keep it this way i move on to another device.

Developing themes is off for the moment since we don’t know where it is going.

1 Like

Hi guys,

Sorry to be a pain but I am having trouble syncing this rollback FW on my USB to my hub.

I have done every step as per  the link below. (several times and re-read the steps again and again…)

http://wdc.custhelp.com/app/answers/detail/a_id/5860/~/how-to-roll-back-the-firmware-on-a-wd-tv-live…

and have renamed the version to a higher number as per TW… I dont understand why this is not working at all for me.

I dont know why the hub is not reading the data on the USB…

the data bar shows up on screen as to upload the data but within a second or two… its done. The hub did not form a upgrade at all  which is the missing step when I am following the step by step guide.

What is going on here…?

  

Did you download the firmware from the linked page you have in your post.  If you did you shouldn’t change the firmware version, that was step was only for the standard firmware.  The one you download from the rollback link is already setup to rollback and you don’t have to do anything to it.

TW,

The very first time I  try to roll back, I didnt change the version. Still the FW didnt upgrade.

I changed the version later on to see if it would work… But nothing.  

I will try it again today without the renaming the version and see how that goes.

Thanks for your help.

Is it possible this could be a cache issue?  Let me first clarify I am using anodized trickle with the boxart just my boxart on some movies are gone not all and the select few that I did in jpg to png will not show at all. The reason I say this is because if I go into thumgen and recreate the same thumbs they work unless the hub now takes them as they come in and resizes them. Also Before the firmware .jpg format would work but only for the thumb not the movie pic in the upper left when highlighted in gallery view now with a .jpg it shows both pics. Then on the ones that I lost the boxart on they will show the whole pic boxart and everything in the left side in gallery view and just a thumb at the bottom. I realize the jpg to png is probably lost and broken but maybe not so on the jpgs I am not good at this but maybe this will help in figuring it out.

Well, you are somewhat correct that it is a caching issue, since part of the problem is that the HUB uses cached images and not the actual image that is associated with the file.  The problem though is not that it caches the image, but in how it caches the image.

Now, don’t take this to the bank, because this is just what I can divine from looking through the firmware.  But one problem seems to be in how it handles non .jpg images. The reason true .pngs can’t be displayed is because instead of caching the .png “as is”, it appears to take any non .jpg image and convert them to .jpg before caching.  So instead of doing this:

image.png -------> cache --------> display

it does this:

image.png -------> convert to .jpg ---------> cache --------> display

The reason the .png to .jpg work-around worked prior to the latest firmware is most likely because by doing this it tricked the firmware into thinking that it was just a .jpg and skipped the converting process and just cached the image.  Now with the new firmware it seems that instead of caching the .png>.jpg it doesn’t appear to see that image as an image so it doesn’t cache it.

Also, as for the images being cutoff, this appears to be a problem with how the firmware implements scaling.  From what I can tell, instead of using the ratio of the thumbnail and scaling it accordingly, it uses a set ratio and no matter the size of the thumbnail it scales the thumbnail to that ratio.  Most likely this is a bug in the fixed ratio settings since even with the scale type set in the xml to “fixratio” it actually acts like “pan”.

I also just wanted to add.  Another problem is the size in which the HUB caches the images.  It does not cache the thumbnails at the size that they are, but rather in order to increase speed, it caches them at much smaller size.

This is why, at least with .jpgs (and it seems to be the same case with true .pngs), they become pixelized and distorted when displayed at either at the size of your actual image or larger.

TW if I may add a few words.

The thumbnail dimensions are based on the theme and view mode.

The Hub is creating thumbnails for each view mode individually .

If the theme requests a thumbnail size of 134x201 it will create create it, overcompress it and put it into the thumbs folder

If you’d change your theme settings to 135x203 it would do the same thing again and is deleteing the former 134x thumbnails.

THUMBNAILS

On a positive note, it is faster and library mode is no longer needed to display the poster image that is used for trickles.

On a negative note, it disables trickles completely due to the cropping.

Here a Rumor froma German retailer that claims to know…  I take no responsibility for the content in this statement, just offering a possible answer:

He said that the overload of images by using full screen images as thumbnails has caused physical memory breakage and Western Digital is using this new cropping scenario as a prevention for that.

(again, just offering this rumor, i wouldn’t know if any of that is true)

DeVicious wrote:

Here a Rumor froma German retailer that claims to know…  I take no responsibility for the content in this statement, just offering a possible answer:

He said that the overload of images by using full screen images as thumbnails has caused physical memory breakage and Western Digital is using this new cropping scenario as a prevention for that.

(again, just offering this rumor, i wouldn’t know if any of that is true)

 

If that was translated from German to English breakage may be reffering to like a memory overload. The result being hosed up data? Can’t see how you could break a memory chip…but then what do I know…just sayin’