.

SanDisk MP3 players Sansa® Fuze™
21

Re: White-screen crash - I converted three full-length movies from AVI sources. Two white-screen crashed the Fuze. They were all XviD; two had 6ch AC3, while one had VBR MP3. One of the AC3s worked. All three worked fine on the PC, just the Fuze had problems. Without doing lots more encodes, I can’t see any commonality. If you do, tell me.

I feel pretty safe in saying that DVD conversions (i.e. from VOBs) would not white-screen. Just the stuff that were already converted would potentially crash.

Workaround: Use a different converter to convert the ‘problem’ videos as an intermediate step, then feed the converted-converted movie to the script to be converted. Uh, yeah, something like that…

Re: Seek crash - From my AVIMux script (avimux.script):

LOAD C:\Vidz\temp_output.avi
SELECT FILE 0
ADD VIDEOSOURCE
WITH SET OPTION
  RECLISTS 0
  MP3 CBR FRAMEMODE 0
  STDIDX 3000 FRAMES
  AVI RIFFAVISIZE 700
  AUDIO INTERLEAVE 2 FR
  PRELOAD 0
END WITH
WITH SET OPTION
  OVERWRITEDLG 0
  DONEDLG 0
  CLOSEAPP 1
END WITH
START C:\Vidz\FINAL_OUTPUT.AVI

The options inside the first WITH block are the custom params passed to AVIMux for the Fuze’s setting requirements. Thanks to Liqsquid and by trial & error, I’ve ascertained that the two params responsible for seek-crash are the STDIDX and AVI RIFFAVISIZE.

If LEGACY is set to 0 (i.e. no RIFFAVISIZE), seek crashes at 22-ish sec mark.
If RIFFAVISIZE is set to 1, seek crashes at 22-ish sec mark.
If RIFFAVISIZE is set to 10, seek crashes at 3:30-ish min mark.
If RIFFAVISIZE is set to 100, seek crashes at 38-ish min mark.

Conclude: RIFFAVISIZE setting is dependent on vid length. Ewelot’s 999 setting is certainly good enough, although AVIMux recommends that the size be set as small as possible. Assuming a max of 4-hr video length, it’s safe to have it at 700.

For STDIDX (tested on 2 movies: 58min, 2:08hr)
1000 frames: still crashes but rarely (once in seeking thru 56m vid several times)
 500 frames: 58min video truncated to 45min, crashes sometimes
3000 frames: no crash by seeking (partial & full seeks) thru both movies several times

Conclude: STDIDX 3000 seems most stable from my obviously limited testing. If you run into seek-crash issues, try changing this setting in the file ‘avimux.script’.

22

It’s not working again.

I spoke to soon.  As soon as it finished with the command prompt, another program opened, that AVI-MUX program, started doing something, then my security program came up saying that it was trying to open something, so I allowed it.  Then the program crashed and Windows said it had to close it, and it was sorry for the inconvenience.  What am I doing wrong?

Also, in the first post, it says it freezes up the Fuze, and makes the screen go white, so is that permanent, or does a reset fix that? 

23

The shell script pops up a console and invokes mencoder to convert the video. Once done, the script calls AVIMux with avimux.script. AVIMux pops up, loads temp_output.avi per avimux.script’s direction, and writes it back out with specified mux settings to FINAL_OUTPUT.avi. Everything is done within C:\Vidz folder.

If the AV app blocks AVIMux or even interferes with its scripted run, then it will probably crash. AVIMux scripting is pretty primitive. Set the AV app to allow AVIMux to run, or turn it off for the duration.

For the security conscious: Get AVIMux & mencoder from the source; they’re listed in readme.txt. The only other files are the scripts, which can be examined in Notepad.

For the ultra-paranoid: Do the above. Open a console window and run mencoder.exe directly, by copy-pasting the mencoder parameters from the script. Drop avimux.script into Notepad and examine it. Run AVIMux with avimux.script when mencoder finishes.

If you get a white-screen crash, do a soft reset, i.e. hold the slider at the Off position until it turns off. The Fuze retains all of the settings. That said, like all programs of its type, it’s offered on an as-is basis and there’s no guarantee. Any consequence that arises from its use is your sole responsibility. Hmm, I should put this legalese stuff inside the readme.txt as well.

24

Thank you for the option to change wide screen format to 4:3 with the CONVERT_PanScan.cmd option that you have.  This is the feature I have wanted.

25

Message Edited by TomJensen on 04-18-2010 04:11 AM

26

I allowed everything to go through my security system, and it’s still crashing.  Is there anything that can solve this? 

27

Added script logic for multiple concurrent conversions. Updated to v0.4

@saxmaster

My guess is that your anti-virus is Evil, and you should do an exorcism. Try, in order of difficulty:

. disabling it entirely for the duration of the conversion

. booting to safe mode (F8 on boot-up)
. uninstalling the app, or at least don’t use it in resident mode
. find another PC to test
. clean Windows install

28

Added batch processing capability for non-DVD sources. Updated to v0.45.

29

Switched to fuzemux for re-muxing. Thanks to earthcrosser for the util. Updated to v0.46.

30

Message Edited by TomJensen on 04-18-2010 04:13 AM

31

Hm sems that I should look into that concurrent conversion thingy for v4f lol

32

It worked!

I decided to try to give the worst thing possible . . . a whole movie.

It converted it in probably about 5 to ten minutes (With the Sansa Media Converter, it took more than an hour if I remember it correctly) and it is now on my Fuze successfully!  I recommend this now because it is very fast . . . compared to SMC.

33

I was using XMedia Recode to resize my AVI movies and then passing them through the Sansa Media Converter to load them onto my Sansa Fuze; it was taking on average 45 mins for each movie. In addition, if I deleted a movie from the Sansa Fuze, I had to pass them through the Sansa Media Converter again (about 10 mins each time). I’ve used FuzeVid 0.46a (using CONVERT_PanScan and VIDQUAL=2) for four movies now (each takes anout 10 mins to convert) and they’ve each converted successfully and then I dragged-and dropped them onto my external microSD card and they seem to be playing fine (but more testing needed with more movies). So far, this appears to the simplest and fastest way for getting acceptable quality movies on my Sansa Fuze, thank you.

34

@ssorgatem

Let me know if you try mencoder-mt and get it to work. With threads=2, my dual-core was only getting a 60% workload (as opposed to 50% in single-thread), and speed was same or slightly slower than single-thread mode. I only tried it once, though.

I thought about running a CPU checker to spawn jobs == # of cores detected. But speed isn’t a big concern, so I KISS’ed.

@saxmaster765

Glad you finally got it working. I think the problem before was that your AV app didn’t like AVIMux, which is now gone.

@writedoc

Keep an eye on the bitrate (suggest MediaInfo). If it gets close to 900Kbps, the Fuze may not be able to keep up, and it will progressively lose sync. Music videos and very intense action movies (Transformers) would be most susceptible, as they burn a lot of bits. Vidqual=3 is probably the safest best-quality setting to use.

Vidqual is the quantizer used. As a comparison, 1CD AVIs use Q3-5, mainly 4. 2CD AVIs range Q3-4. A constant Q3 is akin to a 3CD encode, and Q2 is ~4CD.

35

Message Edited by TomJensen on 05-03-2010 05:34 PM

36

I also happen to like the fact that the video and audio lined up through the whole full length movie.

37

@tomjensen wrote:

Limitations:

 

. If video name or the path to it has non-ANSI characters (e.g. Unicode), it will not be recognized by the script due to the font limitation in Windows console. If so, rename video or move it to an ANSI-compliant path before drag&drop.

Ah, windows console. It’s so frustrating. I ended up having to do weird things in v4f to make it recognize unicode filenames on windows. I got it working on wine better than in windows itself.

Mmm, what are the advantatges of your scripts when compared to v4f? Because if your scripts’ defaults are better than v4f’s, it should be good to change v4f’s. I’m not a mencoder expert, so I’m open to suggestions.

Or the differences at least. I tried to read the code, but all those gotos and weird words with lots of %% and ~ got me lost.

Also a suggestion: a installer would make live easier to end-users, and Program files (there’s a variable for it, right? i’m pretty sure I use it in the instaler for v4f) would be a better place to put FuzeVidz, instead of C:. I’ve seen windows installation where windows is not in C: but in E: or F:.

PD: Ok, i’ve just seen a point where your script clearly wins v4f: it can work on pre-NT windowses, where v4f won’t. I think. 

38

Message Edited by TomJensen on 05-03-2010 05:35 PM

39

Yeah, I’m also a KISS guy. Different points of view, I guess. That’s why open-source is so great: “Don’t like it? Make your own!”.

Well, I did have a machine with dual boot Vista and XP. Vista partition was C: and XP partition was E:. In both Vista and XP. That confused a lot of programs in XP and vista got upset about it, eventually feeling not genuine when it actually was OEM.Well, that box isn’t running windows anymore :slight_smile:

 I’ll into that single pass thing. I think I got to the conclusion that 2 pass was better, but I cannot remember why (that was august, a long time ago…).

40

Message Edited by TomJensen on 05-03-2010 05:35 PM