Topic: Insignia infocast

I just bought the insignia infocast today. I have the Sony Dash also. My gripe with the Sony is while the alarm will fire off Pandora just fine two minutes into the music it starts beeping over the music and there is no way to stop it. Sony calls it a "feature" and the beep can't be disabled. Now for the Insignia I can't find a way for the alarm to trigger Pandora to play or trigger any music to play. I FIND THIS AMAZING THAT AN ALARM CLOCK CAN'T PLAY MUSIC AS AN ALARM. Am I missing something? Otherwise I do like the Insignia better than the dash but this alarm oversight is crippling.

thanks Andy

Re: Insignia infocast

It's not an alarm clock.

It does not claim to be an alarm clock. It does not say that's it's an alarm clock on the box. It does not say that it's an alarm clock on the shelf.  It does not say it's an alarm clock on this site or Best Buy's site.

Why do you think it's an alarm clock?

Re: Insignia infocast

WOWWWW..... I didn't mean to insult anybody. Let me rephrase. This "platform" has an alarm clock application in which the "application" will not trigger other applications, ie Pandora. Quite frankly Best Buy is marketing it to consumers who are not developers. To the consumers it is the applications that make the platform shine:)

Re: Insignia infocast

I'm not taking it as an insult.  I just don't understand this (all caps, no less) statement:

I FIND THIS AMAZING THAT AN ALARM CLOCK CAN'T PLAY MUSIC AS AN ALARM

...with regard to the Best Buy Infocast.  You are correct that Best Buy is selling it to consumers, but they're not even *pretending* that one application would trigger another application.

I suppose that it might have been best if Best Buy had eliminated even the trivial alarm in order to reduce the apparent confusion.

Re: Insignia infocast

Never mind this thread isn't worth it.

Re: Insignia infocast

Look - if you have some issue with the feature set of the Infocast, please contact Best Buy.  I'm sure they'd be very interested in your feedback.

Accordingly, if you have some issue with the Sony dash, please contact Sony.

These are their products, and they choose the feature set, not us.  If you can convince them that the alarm functionality should be enhanced, then I'm sure we'd get involved.

Re: Insignia infocast

Try to contact Bust Buy.......lol. I found the forum the only source of information.

Re: Insignia infocast

For what it's worth, I found this site (Insignia Forum) and it may help.

http://community.insigniaproducts.com/

It's cumbersome and a pain to sign up, but I made it through and will go from there.

Re: Insignia infocast

Did anyone find any references to the infocast Insignia Forum? I didn't see any.

10 (edited by burkhardi 2010-06-23 04:58:05)

Re: Insignia infocast

abarron wrote:

Did anyone find any references to the infocast Insignia Forum? I didn't see any.

No, I search for both Infocast and NC-DP8CH
So I made a post in two forums that were the closest match asking where to post.
Once I get an answer, I'll edit this post as well as add to the Infocast main thread too [The Insignia/BestBuy branded Chumby].
Regards, Matt

EDIT:
An Insignia person names John replied to my post, so let the feedback roll...
http://community.insigniaproducts.com/t … 11331#M953

Re: Insignia infocast

I'll tell you what - we'll collect suggestions about the product and forward them to the folks at BBY.

I know that at least some of them monitor this forum, even if they don't actually post here.

Re: Insignia infocast

I took apart my Infocast and behold the the files are all located on a micro sd card. I put in my computer (running linux) and found the alarm files. Also there is 3 filesystems located on it, 1.6 gb of user memory and two 189 mb for system use

Re: Insignia infocast

@phoenixflames The first partition actually contains a proprietary simple-filesystem that's used to hold the bootloader and init code.  The same partition format is used on the chumby One.  I don't think it's documented on the wiki, but there's a program in the utils-1.0 package that can manipulate it called config_util.  It's got a structure like:

typedef union {
    char name[4];
    unsigned int uname;
} block_def_name;

typedef struct _block_def {
    unsigned int offset;        // Offset from start of partition 1; if 0xffffffff, end of block table
    unsigned int length;        // Length of block in bytes
    unsigned char block_ver[4]; // Version of this block data, e.g. 1,0,0,0
    block_def_name n;       // Name of block, e.g. "krnA" (not NULL-terminated, a-z, A-Z, 0-9 and non-escape symbols allowed)
} block_def;

typedef struct _config_area {
    char sig[4];    // 'C','f','g','*'
    unsigned char area_version[4];  // 1,0,0,0
    unsigned char active_index[4];  // element 0 is 0 if krnA active, 1 if krnB; elements 1-3 are padding
    unsigned char updating[4];  // element 0 is 1 if update in progress; elements 1-3 are padding
    char last_update[16];       // NULL-terminated version of last successful update, e.g. "1.7.1892"
    unsigned int p1_offset;     // Offset in bytes from start of device to start of partition 1
    char factory_data[220];     // Data recorded in manufacturing in format KEY=VALUE<newline>...
    char configname[128];       // NULL-terminated CONFIGNAME of current build, e.g. "silvermoon_sd"
    unsigned char unused2[128];
    unsigned char mbr_backup[512];  // Backup copy of MBR
    block_def block_table[64];  // Block table entries ending with offset==0xffffffff
    unsigned char unused3[0];
} config_area;

The actual partition data begins at offset 0xc000 of the partition.

It'd be interesting if someone wrote a filesystem driver for it smile

Re: Insignia infocast

Hey ChumbyLurker, I may be incorrect in this but is the Infocast's kernel handled in the same fashion as the C1? I ask because after getting a kernel recompiled with a different build number I was unable to get the system to actually recognize it.

I found that the silvermoon update.sh worked just like the C1 with its use of the config_util and I dug through that and got a grasp on how the partitioning and flags worked. I checked the offsets for krnA and krnB by doing a hexdump of the partition and saw the byte pattern of the zImage in each area.

I used putblock, set the updating flag to 0, did a few sync operations, and rebooted but it was still the same build that came up. After a bit I decided to try to see if I was having any influence with writing to those areas and piped /dev/zero over krnA and krnB. The overwritten areas persisted a reboot and I still had a working kernel. Is the kernel pulled from elsewhere of a checksum fails or in the event that it looks as though a failure has occurred? U-Boot in the partition was definitely having an influence, though, when I modified that smile.

At that point I started to look at the /boot/vmlinuz file, but I really haven't made much headway with having a custom kernel that the device would actually boot to.

Re: Insignia infocast

@devOut The bootloader on Infocast is actually much smarter than the one on the chumby One, because it's a full u-boot environment.  It supports reading ext2 images, so the boot logo and kernel are all read off of the root of the device to be booted to.

If it can't read that file, it pulls it out of the config block.

To update the kernel, you'll want to replace /boot/vmlinuz with arch/arm/boot/zImage out of your kernel build tree.

Interestingly, you can also replace the boot logos by replacing the *_insignia.gz files with gzipped RGB565 raw bitmaps.

Re: Insignia infocast

Yeah, I had tried replacing the vmlinuz but did not have a bootable system after that. It pretty much hung at the uboot splash. It could be from the kernel modules having a version mismatch, but I know that using the composite-out kernel posted to the forums with an updated C1 would fail at loading the 802.11 drivers but would still boot to an otherwise working system. I saw the logo files in the boot folder and those+the ones in the video/logo area of the kernel tree seem to be read without issue by GIMP.

I am unfortunately away from my Infocasts this weekend but I will have another go Monday. Knowing that replacing the vmlinuz and getting a freeze (as I've been to at this point) is on the right track I will try recompiling and replacing the modules as well.

Re: Insignia infocast

Duane wrote:

I'll tell you what - we'll collect suggestions about the product and forward them to the folks at BBY.

I know that at least some of them monitor this forum, even if they don't actually post here.

I picked up my Infocast yesterday at Best Buy.  I spent the morning trying to figure out how to play a Shoutcast station when the alarm goes off.  I notice the feature is included in the 3.5" version.  Anyway, add me to the list of people who would like to see this feature added.

Re: Insignia infocast

Raddle wrote:

I picked up my Infocast yesterday at Best Buy.  I spent the morning trying to figure out how to play a Shoutcast station when the alarm goes off.  I notice the feature is included in the 3.5" version.  Anyway, add me to the list of people who would like to see this feature added.

I thought a bit more about this.  The probelm could be solved if Shoutcast or some other app could create an app for each Internet radio station.  We could then create a channel with this single (or multiple) radio stations and set the alarm to start that channel.  That way, the basic Infocast software doesn't have to be modified.

So, are there any app developers out there who want to take this on?  You will have the gratitude of the Infocast and Chumby communities.

Re: Insignia infocast

To have more "play" room and not to mess up the original microsd card I copied it to a new microsd card.

I found out that I would have issues with a copied microSD card from my running Infocast.  I ended up copying a "virgin" (DD'd) image from an unused/not set up Infocast to a 4,8 and 16 GB microsd card.  From this I had a look see with the Linux box and removed partition #4 from it.  When it booted up the first time it created a new partition and filled the microSD card.

Ideally though a rewrite of the UBoot partition such that it'll look for the USB dongle first either loading the OS from the USB dongle or if not found the regular Chumby OS would be great - similiar to what went on the the Sheeva Seagate Dockstar stuff.  This would enable a kind of plug n play experimenting with the Infocast.

Re: Insignia infocast

pete_c wrote:

Ideally though a rewrite of the UBoot partition such that it'll look for the USB dongle first either loading the OS from the USB dongle or if not found the regular Chumby OS would be great - similiar to what went on the the Sheeva Seagate Dockstar stuff.  This would enable a kind of plug n play experimenting with the Infocast.

This is also my dream.  It's here for us to hack:
http://files.chumby.com/source/openembe … 129.tar.gz

There were patches floating on the u-boot lists that could perhaps produce an MMC-compatible fw_printenv & fw_setenv.  It would be awesome for u-boot to find a usb mass storage and boot, or even, a usb ethernet and do netconsole so we don't have to solder the serial of each device to play in u-boot.

I don't know how far fetched this is, but once we have a Doozan-style (Dockstar/*plug) u-boot, it'll be much less hassle to experiment with other OSes on the device...

Re: Insignia infocast

I've been playing with just utilizing the /mnt/storage partition to autoboot stuff and its been working OK for the time being without an additional USB memory stick.

So far just syncing time, creating shares, running a python script and an XPL hub with autoboot up using existing kernel.