תיקון ComfyUI Manager שלא מזהה Custom Nodes מותקנים

התקנתם custom nodes ב-ComfyUI, הם יושבים ממש שם בתיקיית custom_nodes שלכם, אבל ComfyUI Manager בעקשנות מציג אותם כ"לא מותקנים". אתם לוחצים על התקנה שוב והוא יוצר כפילויות. או שאתם מנסים לעדכן אבל הוא אומר שאין מה לעדכן למרות שאתם יודעים שקיימות גרסאות חדשות.

תשובה מהירה: ComfyUI Manager שלא מזהה nodes מותקנים נובע בדרך כלל מחוסר סנכרון של מסד הנתונים, שיטות התקנה לא נכונות, או התנגשויות של metadata במטמון. התיקון כולל בדרך כלל ניקוי מטמון מסד הנתונים של nodes של המנג'ר, וידוא ש-nodes הותקנו דרך המנג'ר ולא על ידי git clone ידני, ואימות שמבנה התיקיות תואם לציפיות המנג'ר. הפעלה מחדש של המנג'ר או בנייה מחדש של מסד הנתונים פותרת את רוב המקרים תוך דקות.

בעיה זו נמנית עם התסכולים הנפוצים ביותר של ComfyUI שמדווחים על ידי משתמשים. זה מעצבן במיוחד כי ה-nodes שלכם עובדים מצוין ב-workflows. הם נטענים בסדר, מתבצעים ללא שגיאות, אבל המנג'ר חושב שהם לא קיימים. בואו נתקן את זה באופן שיטתי.

למה ComfyUI Manager לא מצליח לזהות nodes?

הבנת הגורם השורשי עוזרת לכם לתקן את זה נכון ולמנוע הישנות.

איך המנג'ר עוקב אחר התקנות

ComfyUI Manager לא רק מסתכל על תיקיית custom_nodes שלכם. הוא מתחזק מסד נתונים פנימי שעוקב אחר מה שהתקין, מאיפה, ואיזו גרסה. מסד נתונים זה נמצא במבנה התיקיות של המנג'ר עצמו.

כשאתם משכפלים ידנית repository של node באמצעות git, ה-node עובד כי ComfyUI עצמו רק סורק קבצי Python ב-custom_nodes. אבל המנג'ר לא יודע על זה כי שום דבר לא עדכן את מסד הנתונים של המנג'ר.

גם ההפך קורה. אם מסד הנתונים של המנג'ר אומר שמשהו מותקן אבל התיקייה נמחקה או הועברה, המנג'ר מציג אותו כמותקן כשבעצם הוא חסר.

גורמים נפוצים לחוסר סנכרון

פעולות git ידניות הן הגורם העיקרי. שכפול, משיכה, או הסרה של תיקיות nodes ללא מעבר דרך המנג'ר שובר את המעקב שלו.

התקנות שנכשלו יכולות להשאיר רשומות חלקיות במסד הנתונים. המנג'ר ניסה להתקין משהו, נכשל באמצע, אבל רשם אותו כמותקן לפני הכישלון.

העברה או העתקה של התקנות ComfyUI לעתים קרובות משאירה את מסד הנתונים של המנג'ר מצביע לנתיבים שגויים או עם מידע מיושן על המערכת הקודמת.

עדכוני מנג'ר מדי פעם מציגים שינויים בסכמת מסד הנתונים. פורמטים ישנים של מסד נתונים עלולים לא להיות מנותחים נכון לאחר עדכון המנג'ר עצמו.

הפרעת אנטי-וירוס לפעמים מוחקת קבצים במהלך ההתקנה אבל אחרי שהמנג'ר רשם את ההתקנה כמושלמת. המנג'ר חושב שזה הצליח אבל הקבצים נעלמו.

שכבת המטמון

המנג'ר גם מאחסן במטמון metadata של nodes כמו עדכונים זמינים ומידע על repository. מטמון זה יכול להיות מיושן או פגום, ולהציג סטטוס לא עדכני או לא נכון גם כשמסד הנתונים הבסיסי נכון.

בעיות מטמון גורמות לתסמינים כמו "עדכון זמין" שלא מופיע אף פעם, או מספרי גרסה לא נכונים שמוצגים בממשק המנג'ר.

איך מתקנים בעיות זיהוי nodes?

התחילו עם הפתרונות הפשוטים ביותר והסלימו אם צריך.

פתרון 1: הפעלה מחדש מלאה של ComfyUI

לפעמים המנג'ר רק צריך אתחול חדש. סגרו את ComfyUI לחלוטין - לא רק רענון, אלא עצירת תהליך Python.

חכו כמה שניות שה-handles לקבצים ישתחררו, ואז הפעילו את ComfyUI שוב. המנג'ר מתאתחל מחדש בהפעלה ועלול לזהות nodes שהחמיץ במהלך סשן ארוך.

צעד פשוט זה מתקן את הבעיה בכ-20% מהמקרים ללא סיכון.

פתרון 2: אילוץ בנייה מחדש של מסד הנתונים של המנג'ר

למנג'ר יש פונקציה מובנית לבנות מחדש את מסד הנתונים של nodes ממצב מערכת הקבצים.

פתחו את המנג'ר ב-ComfyUI על ידי לחיצה על כפתור המנג'ר. נווטו להגדרות או אפשרויות מתקדמות. חפשו אפשרות שמסומנת "Rebuild Database" או "Rescan Nodes".

לחיצה על זה מאלצת את המנג'ר לסרוק את ספריית custom_nodes מחדש ולבנות מחדש את רשומות ההתקנה שלו. כל nodes קיימים יזוהו ויירשמו כראוי.

אחרי הבנייה מחדש, הפעילו מחדש את ComfyUI כדי שהשינויים ייכנסו לתוקף מלא.

פתרון 3: ניקוי מטמון מסד הנתונים של nodes

אם בנייה מחדש לא עוזרת, נקו את קבצי המטמון ידנית. נווטו לספריית ההתקנה של ComfyUI.

מצאו את תיקיית ComfyUI-Manager בתוך custom_nodes. בתוך תיקיית המנג'ר, חפשו קבצים בשם כמו node_db.json, cache.json, או קבצי מסד נתונים דומים.

מחקו את קבצי המטמון האלה. אל תדאגו, הם ייווצרו מחדש אוטומטית כשהמנג'ר יופעל מחדש. מסד הנתונים החדש ישקף במדויק את ההתקנות הנוכחיות שלכם.

הפעילו מחדש את ComfyUI אחרי מחיקת קבצי המטמון. המנג'ר ייקח קצת יותר זמן בטעינה הראשונה כי הוא בונה מחדש הכל מאפס.

פתרון 4: התקנה מחדש של nodes בעייתיים דרך המנג'ר

עבור nodes ששכפלתם ידנית, התיקון הנקי ביותר הוא התקנה מחדש דרך המנג'ר.

ראשית, מחקו את התיקייה שנשכפלה ידנית מ-custom_nodes. אל רק תשנו שם כי זה יכול לגרום לבעיות אחרות.

אז השתמשו בממשק Install Custom Nodes של המנג'ר כדי להתקין את אותו node. המנג'ר ישכפל אותו כראוי וירשום אותו במסד הנתונים שלו.

גישה זו מבטיחה שלמנג'ר יש מעקב מלא ויכול לטפל בעדכונים, תלויות, והסרה נכון מעכשיו והלאה.

פתרון 5: בדיקת שמות תיקיות

המנג'ר מצפה לשמות תיקיות ספציפיים שתואמים לשמות repositories. אם שיניתם שם של תיקיית node, המנג'ר לא יכול להתאים אותה לרשומה במסד הנתונים שלו.

בדקו ששמות התיקיות תואמים למה שהמנג'ר מצפה. ל-repository ComfyUI-Impact-Pack צריכה להיות תיקייה בשם בדיוק ComfyUI-Impact-Pack, לא Impact-Pack או משהו מקוצר.

אם שיניתם שמות של תיקיות, או שנו אותם בחזרה או התקינו מחדש דרך המנג'ר כדי לקבל את השמות הנכונים אוטומטית.

פתרון 6: אימות סטטוס Git Repository

המנג'ר משתמש ב-git כדי לעקוב אחר גרסאות ועדכונים. אם תיקיית .git בתוך node חסרה או פגומה, המנג'ר לא יכול לקבוע את סטטוס ההתקנה.

נווטו לתוך תיקיית node בעייתי ובדקו אם יש ספריית .git. אם היא חסרה, ה-node לא ייעקב כראוי.

אתם יכולים לנסות להריץ git init ואחריו להגדיר את ה-remote ל-repository המקורי, אבל התקנה מחדש דרך המנג'ר בדרך כלל פשוטה יותר.

פתרון 7: בדיקת התקנות כפולות

לפעמים אותו node מותקן פעמיים עם שינויי שם קלים. המנג'ר עלול לעקוב אחר אחד בעוד ComfyUI טוען את השני.

חפשו כפילויות בתיקיית custom_nodes שלכם. חפשו תיקיות עם שמות דומים או פונקציונליות node זהה. הסירו כפילויות, והשאירו רק את זה שהותקן דרך המנג'ר.

דפוסים נפוצים של כפילויות כוללים את שניהם - שם ה-repository המקורי וגרסה ששמה שונה, או שני ה-branches - ה-release וה-development של אותו node.

מה אם nodes מציגים מספרי גרסה שגויים?

בעיות זיהוי גרסה קשורות אבל שונות מזיהוי התקנה.

מנגנון מעקב גרסאות

המנג'ר בודק tags ו-commits של git כדי לקבוע גרסאות. אם repository של node לא משתמש בתיוג גרסאות נכון, המנג'ר מציג גרסאות "unknown" או לא נכונות.

זה לא משהו שאתם יכולים לתקן עבור nodes שלא יצרתם. מפתח ה-node צריך להשתמש ב-git tags כראוי.

מטמון מיושן

נפוץ יותר, גרסאות שגויות נובעות מ-metadata במטמון. נקו את מטמון המנג'ר כמתואר למעלה כדי לאלץ בדיקות גרסה חדשות.

אחרי ניקוי המטמון, המנג'ר מביא את סטטוס ה-repository הנוכחי מ-GitHub או GitLab. זה לוקח רגע אבל מספק מידע גרסה מדויק.

בעיות רשת

אם המנג'ר לא יכול להגיע למארחי repositories, הוא מציג גרסאות מיושנות. בדקו את קישוריות הרשת שלכם וכל כללי firewall שחוסמים פעולות git.

רשתות ארגוניות לעתים קרובות חוסמות פרוטוקולי git. אם אתם ברשת מוגבלת, המנג'ר לא יכול לעדכן את הידע שלו על גרסאות זמינות.

איך מונעים בעיה זו בעתיד?

שיטות עבודה טובות שומרות על המנג'ר וה-nodes שלכם מסונכרנים לצמיתות.

תמיד להתקין דרך המנג'ר

גם כשיש לכם URL של GitHub ואתם מכירים git, השתמשו בממשק של המנג'ר. הדביקו את ה-URL בשדה ההתקנה המותאמת אישית של המנג'ר במקום לשכפל ידנית.

זה מבטיח רישום נכון במסד הנתונים מההתחלה. שכפול ידני צריך לקרות רק בעת debug או פיתוח של nodes.

להשתמש במנג'ר לעדכונים

כשיש עדכונים זמינים ל-nodes, השתמשו בפונקציית העדכון של המנג'ר במקום להריץ git pull בעצמכם.

עדכון המנג'ר מטפל בעדכוני תלויות, מעקב גרסת מסד נתונים, ו-hooks אחרי עדכון ש-pulls ידניים מדלגים עליהם.

להימנע ממניפולציה ישירה של תיקיות

אל תמחקו, תשנו שם, או תעבירו תיקיות nodes ידנית. השתמשו בפונקציית ההסרה של המנג'ר כדי להסיר nodes בצורה נקייה.

אם אתם חייבים לבצע מניפולציה על תיקיות ישירות, צפו לבנות מחדש את מסד הנתונים של המנג'ר אחר כך.

עדכוני מנג'ר סדירים

שמרו על המנג'ר עצמו מעודכן. גרסאות חדשות יותר מתקנות באגים בטיפול במסד נתונים ומשפרות זיהוי nodes.

עדכנו את המנג'ר קודם כשאתם מאבחנים בעיות nodes כי התיקון עלול כבר להיות קיים בגרסת מנג'ר חדשה יותר.

למשתמשים שרוצים יכולות ComfyUI בלי לנהל פרטים טכניים אלה, Apatero.com מספק תשתית מתוחזקת באופן מקצועי. Nodes תמיד מותקנים, מעודכנים, ומוגדרים כראוי ללא כאבי ראש של סנכרון אלה.

מה לגבי בעיות זיהוי nodes ספציפיות?

לחלק מה-nodes יש בעיות זיהוי ייחודיות ששווה לטפל בהן באופן ספציפי.

זיהוי Impact Pack

ComfyUI-Impact-Pack מורכב עם הרבה תלויות. בעיות זיהוי לעתים קרובות נובעות מבעיות submodule.

ודאו שתיקיית impact_pack_models קיימת ומכילה קבצים נדרשים. Impact Pack לא יוצג כמותקן כראוי אם קבצי המודל שלו חסרים למרות שהקוד קיים.

השתמשו במתקין המובנה של Impact Pack עבור התלויות שלו במקום ההתקנה הגנרית של המנג'ר. זה מטפל בקבצי המודל נכון.

בעיות ControlNet Preprocessor

ComfyUI-ControlNet-AUX דורש הורדות מודל אחרי ההתקנה. המנג'ר מסמן אותו כמותקן מיד, אבל הוא לא באמת מוכן עד שהמודלים יורדים.

אם nodes של preprocessing נותנים שגיאה, הריצו את scripts הורדת המודלים או תנו להם לרדת בשימוש הראשון. ה-node מותקן לפי המנג'ר, רק לא שלם.

זיהוי Video Helper Suite

ל-VideoHelperSuite יש תלויות ffmpeg ספציפיות שמשפיעות על הזיהוי. אם ffmpeg לא נגיש כראוי, המנג'ר עלול להציג סטטוס התקנה חלקי.

ודאו ש-ffmpeg נמצא ב-PATH של המערכת שלכם ונגיש משורת הפקודה. אז בנו מחדש את מסד הנתונים של המנג'ר.

שאלות נפוצות

למה המנג'ר מציג "Update" עבור node שהרגע התקנתי?

זה קורה כשהתקנתם מ-branch פיתוח אבל המנג'ר בודק את ה-branch הראשי לעדכונים. מספרי הגרסה לא תואמים, אז המנג'ר רואה עדכון זמין. בדרך כלל בטוח להתעלם או אפשר לעדכן כדי לסנכרן ל-branch הראשי.

אפשר להשתמש גם במנג'ר וגם ב-git clones ידניים ביחד?

טכנית כן, אבל clones ידניים לא יופיעו בממשק המנג'ר. הם יעבדו ב-ComfyUI אבל המנג'ר לא יעקוב אחריהם. לחוויה הנקייה ביותר, בחרו שיטה אחת והישארו איתה.

האם בנייה מחדש של מסד הנתונים תשבור את ה-workflows שלי?

לא, בנייה מחדש של מסד נתונים משפיעה רק על המעקב של המנג'ר. ה-workflows שלכם, prompts שמורים, והגדרות nodes נשארים ללא פגע. הכל יעבוד בדיוק כמו קודם, רק עם סטטוס מנג'ר מדויק.

למה חלק מה-nodes מופיעים כמה פעמים ברשימת המנג'ר?

זה מצביע על התקנות מרובות, לעתים קרובות מניסיונות התקנה שנכשלו שהשאירו רשומות חלקיות במסד הנתונים. נקו את מסד הנתונים, מחקו את כל העותקים של ה-node הכפול, ואז התקינו מחדש פעם אחת דרך המנג'ר.

איך אני יודע אם node הותקן דרך המנג'ר או ידנית?

nodes שהותקנו על ידי המנג'ר מופיעים ברשימת Installed Nodes עם מידע גרסה ועדכון מתאים. nodes שנשכפלו ידנית או לא מופיעים בכלל או מציגים גרסה "Unknown" ללא יכולת עדכון.

האם זה משפיע על היכולת שלי להשתמש ב-nodes ב-workflows?

לא, בעיות זיהוי nodes הן בעיית מנג'ר בלבד. ComfyUI עצמו סורק את תיקיית custom_nodes באופן עצמאי וטוען מה שהוא מוצא. ה-workflows שלכם יעבדו ללא קשר לסטטוס הזיהוי של המנג'ר.

למה המנג'ר אומר "no nodes installed" כשיש לי עשרות?

זה מצביע על השחתה או אובדן מלא של מסד הנתונים. ה-nodes שלכם בסדר ועובדים. נקו את קבצי המטמון של המנג'ר לגמרי ובנו מחדש את מסד הנתונים מאפס. הכל יזוהה.

אפשר לגבות את מסד הנתונים של המנג'ר לפני פתרון בעיות?

כן, העתיקו את קבצי ה-json מתיקיית המנג'ר לפני מחיקתם. אם משהו משתבש אפשר לשחזר אותם. אולם, מכיוון שקבצים אלה הם בדיוק מה שאתם מאבחנים, שחזור שלהם ישחזר גם את הבעיה.

מה אם אותה בעיה ממשיכה לחזור?

בעיות חוזרות בדרך כלל מצביעות על בעיית workflow כמו התקנה מחדש של nodes ידנית בין בניות מחדש של המנג'ר. בדקו את ההרגלים שלכם וודאו שאתם משתמשים במנג'ר באופן עקבי לכל פעולות ה-nodes.

האם כדאי לדווח על באגי זיהוי ל-GitHub של המנג'ר?

אם ניסיתם את כל הפתרונות והבעיה נמשכת, כן. כללו את גרסת ComfyUI שלכם, גרסת המנג'ר, מערכת הפעלה, ו-nodes ספציפיים שמושפעים. מפתחים יכולים לזהות אם זה באג ידוע או בעיה חדשה.

סיכום ואסטרטגיית מניעה

בעיות זיהוי nodes של ComfyUI Manager נובעות כמעט לחלוטין מחוסר סנכרון בין מסד הנתונים שלו למערכת הקבצים בפועל. התיקון פשוט כי אתם צריכים לאלץ סנכרון דרך בנייה מחדש של מסד נתונים וניקוי מטמון.

התחילו עם הפעלה מחדש פשוטה. אם זה לא עובד, בנו מחדש את מסד הנתונים. לבעיות מתמשכות, נקו את כל קבצי המטמון ותנו למנג'ר ליצור אותם מחדש.

מעכשיו והלאה, התחייבו להשתמש במנג'ר לכל פעולות ה-nodes. התקינו דרך המנג'ר, עדכנו דרך המנג'ר, והסירו דרך המנג'ר. זה שומר על הכל מסונכרן לצמיתות.

הדקות הספורות שמושקעות בפתרון בעיות עכשיו חוסכות שעות של תסכול עתידי. ברגע שמסד הנתונים של המנג'ר שלכם משקף במדויק את ההתקנות שלכם, עדכונים עובדים חלק, תלויות נפתרות נכון, ואתם יכולים לסמוך על מחווני הסטטוס של המנג'ר.

למשתמשים שמעדיפים לא להתעסק במשימות ניהול טכניות אלה, Apatero.com מטפל בכל התקנת ותחזוקת nodes אוטומטית. אתם מקבלים גישה ל-nodes מוגדרים כראוי ללא דאגות סנכרון מסד נתונים או פתרון בעיות ידני.

שמרו על המנג'ר מעודכן, השתמשו בו באופן עקבי, ובעיות זיהוי אלה יהפכו לדבר שבעבר.